[Date Prev][Date Next][Thread Prev][Thread Next][Author Index][Date Index][Thread Index]
RE>Re- Some X++ constructi
- To: <roger@xxxxxxxxxxx>
- Subject: RE>Re- Some X++ constructi
- From: heh <heh@xxxxxxxxxx>
- Date: 22 Oct 90 12:26:14
- Cc: <xtech@xxxxxxxxxx>
Reply to: RE>Re: Some X++ construction
I disagree. I think that Michaels point on using static member functions for
pseudoConstructors is essentially correct. In the 'early' days, we (esp dean)
were thinking about using pseudoConstructors for conversion functions. These
would not map well to static member functions. However, now that the exclusive
use of pseudoConstructors is the proper construction of objects of a class (or
an appropriate hidden implementation class of an abstract class), having them
be static member functions makes a lot more sense.
By providing a scoping operation, it will help prevent name collisions.
For example, this will help in the current conflict on the creation of
accumulators, which now require different names. Array::accumulator(), and
Set::accumulator() work well, I think. I don't believe there is any
restriction on invoking a static member function of an abstract class, so they
can still create instances of a subclass. The overloading argument is not
germane to this particular point - it's just a separate argument.
Essentially, there should be no change except in the translator for most
code (not strictly true...). The main thing that making these into static
member functions would do is to make use of the compiler name mangling so we
don't have to...
Because we are now using the CONVERT() operation, there is no need for
pseudoConstructors outside of the implementation of the class (as far as I know
- any counterexamples, anyone?).
Of course, this isn't a really big deal, either, and so falls into that
category of good ideas that will get implemented... eventually...