Em 29/10/2009 08:36, Nicolas Cellier <[email protected]> 
escreveu:
> 2009/10/28 <[email protected]>:
> > Em 28/10/2009 17:52, Lukas Renggli <[email protected]> escreveu:
> >
> >>
> >> >> What would be your isAbstract  be useful for?  To know whether
> >> > it is wise to instantiate a class or not
> >
> >> That would be  a pure guess then. Presumably  you will still have
> >> to look at the implementation, at the documentation, at its users
> >> or study the  coding conventions of the project  to know for sure
> >> what to do with the thing.
> > Yes.
> > Thinking  aloud:  if  we want  to  insure  a  class shall  not  be
> > instantiated, shouldn't we put an error in #new of that class?
>  That   would   be  the   shortest   way   to   freeze  you   image:
>  Object>>#freezeMyImage 
   ^self subclassResponsibility

That was not the way I envisaged. . . see below.

>  ...and  you  could  not  create  any instance  of  Object  and  its
>  subclasses  anymore  (but  via   a  few  primitives  bypassing  this
>  mechanism).

Again what I was thinking aloud (and continuing) is less of putting
some 'magical' method in Object that detects if it's abstract or not
but a reasonable way of the programmer when constructing the class put
int in the code:

Say we had:

Object>>isAbstract
   ^false

When a class is added to the system the one would do:


SomeClass class>>new
   ^self raise: Error.

SomeClass>>isAbstract
   ^true

>  Beside, do  you want a runtime  check at each creation?  We would
>  have to cache the information at least...

I don't any use of the mechanism if it is not enforceable
automatically.

Otherwise, I could cynically say that the easiest way to attain the
objective would have the programmer inspect the class code [s]he is
thinking of instantiating!

OTOH, notice that mainstream languages use explicit declarations to
have its classes Abstract, not the way around (I mean having the
programming environment detect using its characteristics).

my 0.01999999....

--
Cesar Rabak

_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to