Re: Package's private parts and protected types

["Randy Brukardt" <randy@rrsoftware.com>]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> wrote in message 
news:4e959c35-34d1-49fb-b1eb-5b298e42610f@z19g2000yqk.googlegroups.com...
>On 9 f�v, 15:47, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
>> I agree that it's good to avoid heap management when possible.
>> But why can't you declare local variables of type My_Interface'Class,
>> initialized with build-in-place function calls?
>
>Synchronized-and-the-like interface types are limited, so the built-in-
>place is indeed really built-in-place (no kind of conversion allowed
>at any stage). The initializer function have to return a class wide
>and return it using an extended return statement which is required to
>return the same exact type/subtype as the one function returns.
>
>This way of doing thing is not compatible with the implementation-
>hiding requirement, as it would require the implementation type to be
>exposed in the public part, so that I could define a public function
>returning this exact type.

I don't buy this at all. The exact types to create can be selected by many 
means (presumably by the parameters). You can use a dispatching constructor 
function in the concrete types, using the factory pattern 
(Generic_Dispatching_Constructor), and roughly organized as Bob noted.

Note that you have this problem with *any* constructor of any tagged type if 
you have any interest at all in allowing future extensions.

It would be nice to have a container for Classwide limited types as the 
problem comes up frequently. We made some initial efforts in that direction 
but had problems with finalization and readability of the results. We then 
turned our attention to those building-block problems and never did come 
back to the limited containers themselves. I suspect that we could do a very 
usable job with the new syntax magic for iterators, accessors, and the like. 
(Presuming that we got those to work out, not there yet.)

                            Randy.