Fixing Default Instances

Re: Default Instances...

TrackBack — Thu, 21 Apr 2005 13:37:00 GMT

Default Instance Considered Harmful...?

TrackBack — Fri, 08 Apr 2005 16:05:00 GMT

re: Singletons and Default Instances

TrackBack — Thu, 27 Jan 2005 01:22:00 GMT

re: Singletons and Default Instances

TrackBack — Wed, 26 Jan 2005 23:10:00 GMT

re: Fixing Default Instances

bill — Tue, 25 Jan 2005 20:42:00 GMT

inheritance would work without any issues

the Attribute would be marked as being inherited and being applicable only to classes and assemblies. So let's say you have class foo, and class bar: inhertis foo. If foo is written as :

<VbNoDefaultInstance()>_
Public Class Foo

Then Bar would inherit that attribute by default. But Bar coudl also overwrite that attribute, e.g.

<VbNoDefaultInstance(False)>_
Public Class Bar : Inherits Foo

And hence Bar could be a default instance but foo could not...... and they all lived cross language cross assembly with visual inheritance happily ever after

(and yes inehrited forms do get def instanced)

re: Fixing Default Instances

bill — Tue, 25 Jan 2005 20:19:00 GMT

Yes, that's what i'm thinking - compiler protection, just like option strict

Well then just to flush out your attribute a bit more(*), what about inheritance?

The only forms that get put into the my.forms collection are those that are in the current executable project only. So what if using visual inheritance the form is declared in a different assembly, but but my new form inherits from it, what happens?

If the derived form has the attribute, obviously it's excluded from the forms collection.
But what if the base form has the attribute? Obviously the guy that wrote the base form didn't want it touched - so does the form go into the forms collection or not? If it _does_ go in, that's a waste of time for the guy that wrote the base form to even include. If it _doesn't_ go in, why would the guy who wrote it in C# care enough or even know that he _could_ add the attribute?

For that point, I don't have a VS2k5 instance nearby to check, but do inherited forms even make into the forms collection anyway? I would hope so

Actually, i think this brings up the biggest problem. Something as big as this, which can completely change the way you write code (dependant on your retardation - sorry, i mean skill - level) is fundamental to the framework. This shouldn't just be a VB thing - it should have been an all or nothing thing, even if it _is_ only vb6 gumbies that want it. That way all the C# and C++ and other .net language people will also have voted in the PFC to not include it, and they would have listened.

OK, well it makes sense to me!

* still just stirring the pot

re: Fixing Default Instances

bill — Tue, 25 Jan 2005 19:53:00 GMT

hi Geoff,

Okay so I see you are viewing the Option Default On/Off as being consuming code only ? That is, it dictates whether or not you can write Form1.Show, but doesn't dictate which forms are actually default instances.

One of the main reasons I choose attributes was so as I could have granular control over what forms appear in My.Forms. That is, I might only allow certain default instances such as my option form, or there may be a special form I really don't want a default instance of used (yeh I know, all of them )

So through Imports and attributes we have fine granular control which means we also have extensibility.. who knows what the future holds right ?

Oh, and the CAPTCHA, nope, no control at all.. it gets me sometimes too I think machines probably can read it better than we humans

re: Fixing Default Instances

bill — Tue, 25 Jan 2005 19:31:00 GMT

I get what you're saying, but I'm not sure I really see the problem.

There'd be a global setting like there is now for the Options - so by default you'd have option defaults on or off, as your preference.

Let's say we default to setting it off.

If in one code file, i manually add a option default on line to the top, then that's exactly what i mean - only in the code in this file does the compiler allow the the compile to happen if any default instances are referenced.

So now let's say we default to on.

If it's manually overridden in particular code file to off, then the compiler throws errors in that one code file saying that the defaults used there can't be.

In both cases, i've manually adjusted one specific file to allow or not allow an action, and in both cases that's exactly what i wanted.

I don't see how partial classes are a problem - each is a code file, and each has it's own requirements - surely if i have a partial class split over two files, I can have option explicit on one and not on the other?

In all cases when defaults are an issue and not wanted, it's the code that _we_ are writing at the time that has to be on guard. If i write a form and someone uses it 'defaultly' (hey, i'm inventing english here!) that's netiher a problem of mine or a concern of mine. However, if _i_ don't want defaults, I can choose to not use them or not. Having a compiler stop you from touching those areas is as good enough for me as having them removed. However, (and i'm using a metaphor very very loosely here) just like I don't think mormons should come to my door preaching god to me (it's up to me, not them, whether i want to beleive in god) I have a real issue with stopping _others_ from touching my stuff in the way I see fit. They should do what they want with it, and if they want to touch it via defaults, they should be allowed to. I might not like them doing it, but I shouldn't stop them.

I'm sure there's a bigger picture here, and i'm really only thinking about forms, not anything else in the My namespace, and I'm sure you still totally disagree with me That's ok, tho. The real point I guess I'm trying to make is that this is something that _must_ have been requested a lot for them to bring it in, even if we see no evidence of it now - so i'm happy to just adjust my habits to welcome the addition, but never actually call it myself. That way, i'm happy because i never get stuck with the issues that defaults bring in, and other people are happy, because they can call their my.forms.form1 and eat it too

(Also note: I'm fighting you on this mostly for the principal of the thing - debate is useful to ensure that you're happy with your own justification, and I couldn't help but take a different approach just to make sure that you can fully justify your reasoning *grin* I quite like your idea really, jsut trying to come up with different solutions, especially this late in the whidbey cycle where large changes are likely not to happen

I'll shut up now...until you decide to respond anyway

(PS: Do you have any control ove rthe CAPTCHA control? I can't tell if it's a zero or an oh i'm supposed to type, and so far i've got it wrong everytime

re: Fixing Default Instances

bill — Tue, 25 Jan 2005 19:11:00 GMT

Hi Geoff,

Options can be applied to a code file. When you consider partial classes, an option allows coding within each partial class as per the code fiel, not the entire class. For example you could have one partial class with Option Strict Off and party down with late binding, and in the other partial class have Strict On.

So Options are not type/entity specific. That is, if you had Option Default Off in one code file, and Option Default On in another, then if we have partial types, then what rules are applied and where ? Which form gets a Defualt Instance generated for it, and in which code file can you call on Default Isntances using the shortened syntax ?

This is why i went with attributes as they are entity/type specific.

I think if we can get the Vb team to see the light on this, we will have macros and tempaltes otu there very quickly that will turn these things off for the experienced VB developer

re: Fixing Default Instances

bill — Tue, 25 Jan 2005 19:05:00 GMT

Thnx Jeff

re: inability to turn it off

bill — Tue, 25 Jan 2005 18:09:00 GMT

If they _have_ to do it (and I wish they didn't) why couldn't they just write a 'Option Defaults On/Off'? While your <VBNoDefaualtInstance> attribute is nice, it's limiting those people who want to (sadly) use it.

With Option Strict On, only the code i write gets checked, and errors generated at design time if i forget to type something.

With an Option Default Off, same deal - if a call is made on something that would ordinarily be using a default instance, a compiler error is thrown, and we get a red squiggly underline.

Or am I missing something?

re: Fixing Default Instances

bill — Mon, 24 Jan 2005 22:03:00 GMT

I admire the way you incorporated hookers into your code.