[Gambas-devel] Arguments of inherited constructors

nospam.nospam.nospam at ...176... nospam.nospam.nospam at ...176...
Mon Nov 30 14:51:59 CET 2009


Benoît Minisini wrote:

> There is a change in the Gambas object model in the last revision,
> about arguments passed to inherited constructors.
>
> Let's suppose that you have the following inheritance tree:
>
> A --> B --> C
>
> When instanciating C,

Your English is excellent but the correct spelling of 'instanciating" is
actually "instantiating" :)

I made a mental note to fiks that in the documentation.

(If your English is as good as know it is, you'll get the joke about fiks.)

> the constructor of A (its _new method) is
> automatically called, then the constructor of B, and finally the
> constructor of C.
>
> If constructors have arguments, they must be passed to the NEW
> instruction.
>
> Before the last change, the arguments had to be sent in reverse order:
>
> New C(Arguments for C._new, Arguments for B._new, Arguments for
> A._new)
>
> Now, they have to be sent in normal order:
>
> New C(Arguments for A._new, Arguments for B._new, Arguments for
> C._new)
>
> They are three consequences:
>
> 1) You can now have optional arguments in the C constructor.
>
> 2) Optional arguments in inherited constructors become mandatory.
> Note that only the initial constructor could have optional argument
> before, which I found finally illogical.
>
> 3) You must check your code! For example, if you created a form whose
> constructor has a string arguments, you had to do that before:

The difference between that and this is another thing I have made a note of
to ficks in the doco :)

> MyForm = New MyForm(StringArgument)
>
> And now you must do:
>
> MyForm = New MyForm(Null, StringArgument)
>
> 'Null' is actually the argument of the Window constructor, which is
> the parent of the Window.
>
> Moreover, with that change, I may be able to fix the constructor
> signature that didn't take inheritance into account until now.

Ok, serious questions....

Is there anything at all that the programmer could pass in place of Null?

If there is, what is it about that formerly Null parameter that
distinguishes it from StringArgument? In other words, is there anything that
will enable your code make a decision that "StringArgument" on its own
really means "Null, StringArgument"? If there is, why force the programmer
to pass a null if that null is unnecessary?

That is, does it make sense for a programmer to be forced to pass Null if
there are codeable rules that can decide what "StringArgument" actually
means in the absence of the Null in "Null, StringArgument"?

If that series of questions doesn't make any sense then I promise to crack
open fewer beers tomorrow.

As an example, assume A --> B --> C

If A can't deal with the parameters, then A passes them onto B.  If B can't
deal with the parameters, then B passes them onto C.

If C can't deal with the parameters, then C says to B, "Yer wot?" And B says
says to A, "Yer wot?"

A asks the programmer, "Yer wot?"

Of course, all of that makes absolutely no sense to me after an hour or more
of trying to get it to make sense, and having polished off a dozen or more
Aussie beers inbetween, I'm in no sit ftate to get it to make sense.

What I'm asking here is probably two-fold:

1) Can you make it easier for the programmer by making code-based decisions
without the need to pass nulls?

2) If so, why not make code-based decisions about what the parameters mean?

That is, essentailly, what the .NET Overrides statement does; It says, "I
can't deal with these parameters, perhaps you can?"





More information about the Devel mailing list