why does VS not need the using System.Reflection; declaration when the ConstructorInfo return value of a function is read into a variable declared with var even though when I mouse over the var it can clearly tell me the actual value type is System.Reflection.ConstructorInfo?
@theVBE-it'srightforme That's one of the benefits of var (type inference) - the namespace is also inferred, which avoids the need to import it explicitly. We're just going through and varifying our entire estate at work, and are removing a huge number of usings in the process.
Look at this way - before type inference, the compiler had no way of knowing which Foo type you were talking about. So you had to tell the compiler, either by fully qualifying the type or by using an import. With type inference, the compiler already knows everything it needs to about the type.
@mansellan So basically by using var you are telling the compiler "you know the output type of this function already so go ahead and assign the variable type without me telling you explicitly"?
var is still strictly-typed, it's just that the type is inferred rather than stated explicitly. It's not like a Variant where the type can change over time.
@mansellan I was wondering how the pervasive usage of var was not like using variants in VBA but this perfectly answers it.
@mansellan hey man "reflection" just sounds like sophisticated stuff
Realistically using var and minimizing using makes the code as readable as possible and I am firmly of the belief that code readability should be the top priority after the code doing what you actually want it to.
@theVBE-it'srightforme the (very) rough equivalent of Variant in c# is dynamic - when it was introduced there were exactly the same concerns. Wisely, they kept dynamic on a very short leash, which prevented C# decending into loose-typed hell.
@theVBE-it'srightforme exactly so. c# 9 extends this even further, types can now be inferred from the target type, so you can now either do var x = new Foo() or Foo x = new()
@mansellan retro is where the readability suffers! it is much less commonly Foo and much more commonly IGotTooVerboseTryingToBeDescriptiveWithMyTypeNames.
implicitly calling the constructor like that is very interesting however, I will try that to see how I like it
oh one other question while I tinker with that - with abstract base class, it is better practice to declare common fields as readonly and pass through the derived constructor or just have them not readonly and assign in derived constructor?
@mansellan so it seems like it completely stylistic between these two depending on the context and class name lol. i guess that is to be expected.
@theVBE-it'srightforme In that basic case yes, but target-typing allows other stuff not possible before. At work we tend to use var for locals (as before), but target-typing for module level fields.
@theVBE-it'srightforme Rule of thumb, if you can make something readonly, you should.
@theVBE-it'srightforme so if you defined private Products _products at the class level, you could then instantiate it with _products = new() in a method. Meant to say class not module, but looking at twinBASIC atm so context-switch fail!
> The quickfix will be really easy once we have implemented extract method; it just needs to make the method private and then use the refactoring action.
No. I've paused evaluation as you can't yet declare constants or set the predeclared attribute. The former I can get around by converting to function but the second has me stumped for the trial project I was looking at. Wayne has said these two items should be along in a week or two.
If sharing makes the class 'global' then probably not at this time as this is likely linked to the PredecalredId thing. You could always ask Wayne directly. I got a pretty fast response to my PredeclaredId question yesterday.
> PREVIEW NOTE: We have restricted the project to contain only 1 single source file. This is because we are aware of a caching issue in the twinBASIC compiler when multiple source files are used.
public property get Source() as IBindingPath implements IPropertyBinding.Source
return this.Source
end property
public property get Target() as IBindingPath implements IPropertyBinding.Target
return this.Target
end property
but it's closer to how a class' public members just implement an interface member in C#
it avoids needing a private member invoking a member on the default interface that does the thing, i.e. default interface can have get+set and the getters can Implements TheInterface.Member
Yeah, it's a but of a double-edged sword. The counter-argument is that there's corssover between the VB6 and VB.Net community, and syntax similarity could help with traction.
TBH, VB.NET always and still struck me as a second class citizen. It's easy to convert VB.NET into C# (but interestingly, not as easy to convert C# into VB.NET, IIRC). Besides, tB is not managed so chasing the .NET audience would be a mistake.
I'm thrilled at the prospect of being able to write a small thing that doesn't require a bloated runtime/framework/whatever. That's good enough for me.
Yes, I think it is a great thing when you're dealing with system programming where a mistake could be a Very Bad Thingâ„¢. But that's not the same domain that BASIC families has dealt in (e.g. making quick solutions for internal processes)
did you know they are trying to implement a OS written in pure Rust?
@mansellan Does this mean 64-bit Excel requires 64-bit tB dlls and I'd have to pay? Would this I used for tlbinf32.dll work: trick stackoverflow.com/a/42581513/6609896 ...or is that a specific case? I.e. should I wean myself off 64-bit Excel/VBA to get the free stuff or can I work with it?
@MathieuGuindon So let me get this right, I can write a 64-bit dll to benefit from 64 bit stuff like large integers, but if I only write a 32-bit dll that never uses LongLong - could I instantiate COM objects from that dll in 64 bit Excel. Or does the "target architecture" of mt tB compilation have to match the version of Excel hosting my VBA?
only win x86 is free. Which I think is pretty genius, as it maps 1:1 onto VB6's domain. Once tB reaches feature-parity, zero reason to cling onto VB6...
Back then, that was probably a big selling point.... you could easily find your mistakes in edit & continue without having to go through the entire compilation process
How does everyone feel about the lack of recasing? Obviously not talking about the horror show in VB6/A, but might be nice to have keywords recase automatically?
@this I don't think you could have an identifer and a type that only differ by case, that would nuke compat. Was just mulling smarter autocase than VBA, so that it would treat the case in the Dim statement as canonical.
wait, ignore that... tB is fine having type and identifier names be the same, it's smart enough to figure it out :-)
Guess that might have knock-on implications for Shared though when he gets there
Class IEnumerator(Of T)
Implements IDisposable
Public Property Get Current() As T
End Property
Public Function MoveNext() As Boolean
End Function
Public Sub Reset()
End Sub
End Class
resists urge to port all of System.Collections.Generic
Kinda getting a "kid in a candy store" vibe - seeing all the annoyances of classic VB that have been established fact for 23 years just... evaporate. :-)
@MathieuGuindon Just pitched it. Wouldn't need to be anything fancy, it could be done with syntax sugar and unwind back to classes-with-empty-implementations during build.
mind you saying that, it would be nice if they could inherit through more than one level...
@Vogel612 Yeah, it's a meme. As in "was in such a hurry to post first that I fat-fingered the post". Not a particularly well known meme though I think.