Class variables in Object

How do I add a class variable to Object?  The system says that vars
beginning with an underscore are reserved for system use.  The four vars
already there are have underscores.  The two I want to declare do not.


Shaping

> How do I add a class variable to Object?  The system says that vars
> beginning with an underscore are reserved for system use.  The four vars
> already there are have underscores.  The two I want to declare do not.

I would be very hesitant to mess with Object.  What are you trying to do?

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

"Bill Schwab" <[hidden email]> wrote in message
news:OAWse.7376$[hidden email]...
>> How do I add a class variable to Object?  The system says that vars
>> beginning with an underscore are reserved for system use.  The four vars
>> already there are have underscores.  The two I want to declare do not.
>
> I would be very hesitant to mess with Object.  What are you trying to do?

I'm porting my event framework from VW.  The variables in place are not
suitable.


Shaping

"Shaping" <[hidden email]> wrote in message
news:[hidden email]...
> > I would be very hesitant to mess with Object.  What are you trying to
do?
>
> I'm porting my event framework from VW.  The variables in place are not
> suitable.

I am not sure I can reasonably explain, or logically convince you, but my
gut feeling tells me that after adding some vars to Object or Object class
some very devious things will start happening.

How about using property mechanism? If I recall correctly
Object>>propertyAt: and Object>>propertyAt:put:

rush
--
http://www.templatetamer.com/
http://www.folderscavenger.com/

Rush,

> I am not sure I can reasonably explain, or logically convince you, but my
> gut feeling tells me that after adding some vars to Object or Object class
> some very devious things will start happening.

Dogs and cats living together in harmony, politicians telling the truth
- who knows :)

My understanding is that Object cannot have instance variables because
it has byte subclasses.  I also know that the VM makes assumptions about
the instance variable layout of some classes (IIRC lots of use of
primitives is a warning sign).  I will defer to Blair on whether the
same extends class variables.

Have a good one,

Bill

--
Wilhelm K. Schwab, Ph.D.
[hidden email]

On Sat, 18 Jun 2005 19:26:35 GMT, Bill Schwab <[hidden email]>
wrote:


>My understanding is that Object cannot have instance variables because
>it has byte subclasses.  

What does that mean?

> How about using property mechanism? If I recall correctly
> Object>>propertyAt: and Object>>propertyAt:put:

It's a possibility.

I'm getting flashbacks.  I think I tried something like this many years ago,
and failed, and decided for that reason and a few others to move to VW.  Now
I'm coming back the other way, mostly for the more tractible GUI-building
situation in Dolphin (VW's Pollock is shaping up nicely, but I just don't
have much time to put into it, these days).  I also prefer David Gorisek's
Source Tracking System to VW's Store, mostly because I'm happier when
everything is in Smalltalk.

Blair, are there specific reasons why does Object is special, in this
regard, or are these limitations merely historical and possibly fixable?


Shaping

Shaping wrote:

> How do I add a class variable to Object?  The system says that vars
> beginning with an underscore are reserved for system use.  The four vars
> already there are have underscores.  The two I want to declare do not.

It's not immediately clear why you'd want to use classvars on Object for any
purpose (either in Dolphin or VW).  The only effect you achieve is to inject
some additional variables into the shared scope of all code attached to classes
derived from Object.  And defining a global or two seems a simpler, cleaner,
and more easily manageable way of getting the same effect (and which will work
for objects that are not subclassed from Object too).

So I'd just define my globals in my package's pre-install script, and remove
them again in it's pre-uninstall script.  (I wouldn't add the global to the
package in this case, because I wouldn't want any current events to be saved as
part of my package definition).

Still, if you /do/ want to take the more clunky approach, and I can't think of
any technical reason why you /mustn't/, then you could either send the usual
class-creation message to nil, with appropriate modifications, e.g:

    nil subclass: #Object
         instanceVariableNames: ''
         classVariableNames:
               '_AssertionFailureSignal
               _DependentsRegister
               _EventsRegister
               _PropertyRegister
               MyVar1
               MyVar2'
         poolDictionaries: '_InstanceBehaviorMasks'
         classInstanceVariableNames: ''

which will cause four popup warning which you would have to ignore since the
ClassBuilder thinks that you are defining variables beginning with _.  AFAICT,
that does not cause the existing values of the _Xxx variables to be lost.

Alternatively, and less inelegantly (IMO), you could negotiate directly with
Object and its class pool, using #addClassVarName: and #removeClassVarName: in
your package's [un]install scripts.

    -- chris

Fernando,

> > My understanding is that Object cannot have instance variables because
> > it has byte subclasses.
>
> What does that mean?

Byte objects, such as Strings and ByteArrays, consist of an array of bytes,
unlike most objects which (in some sense) consist of an array of object
references.  Non-byte objects (pointer objects) use a fixed number of their
"slots" to implement their instance variables, so byte objects, which lack
slots for pointers, cannot have instance variables[*]. (Which is occasionally
an irritating restriction, but it's traditional[**].)   If you tried to add an
instvar to Object, then that would be added to every subclass of Object too
(since instvars are inherited).  But that's impossible since there are byte
subclasses of Object, and they cannot have instvars.

(BTW, that restriction is on /instance/ variables -- no such restriction
applies to /class/ variables, or to /class instance/ variables.)

    -- chris

[*] I suppose that it would be possible for them to have instance variables,
/if/ those variables were restricted to holding 8-bit Integer values -- but
there doesn't really seem to be a lot of point...

[**] I believe that S# removes this restriction.

"Chris Uppal" <[hidden email]> wrote in message
news:42b54a0a$1$38040$[hidden email]...
> Shaping wrote:
>
>> How do I add a class variable to Object?  The system says that vars
>> beginning with an underscore are reserved for system use.  The four vars
>> already there have underscores.  The two I want to declare do not.
>
> It's not immediately clear why you'd want to use classvars on Object for
> any
> purpose (either in Dolphin or VW).

I know.  Most of the reasons relate to scope, readability, and related
linguistic experiments that involve changes in Smalltalk syntax...

  The only effect you achieve is to inject
> some additional variables into the shared scope of all code attached to
> classes
> derived from Object.

That's the intent.

  And defining a global or two seems a simpler, cleaner,
> and more easily manageable way of getting the same effect (and which will
> work
> for objects that are not subclassed from Object too).

This is some motivation for use of the global, but it would be a temporary
measure.

I will try this later.  Right now I'm in the middle of porting about 300
classes to Dolphin, and the end is not yet in sight.


Shaping

Shaping wrote:
> How do I add a class variable to Object?  The system says that vars
> beginning with an underscore are reserved for system use.  The four vars
> already there are have underscores.  The two I want to declare do not.

At least in Smalltalk-80 derived dialects there is an API looking like
        SomeClass addClassVarName: aStringOrSymbol
        SomeClass removeClassVarName: aSymbol


Folks, he's not talking about instance variables (class or otherwise) ...
--
_______________,,,^..^,,,____________________________
Eliot Miranda              Smalltalk - Scene not herd

Blair, what's up with defining extra class variables in Object?


Shaping

Shaping,

Erm.., nothing AFAIK. Why can't you just define them as normal, i.e.,
by editing the definition and recompiling. The method comment is just
warning you not to rename or remove the ones that are already there
that begin with an underscore. YOu can give them any names you like,
although preferably not beginning with underscore.

You can't, however, add instancve variables to Object.

The major problem will be how to export your change as part of a
package. The Dolphin package system does not have the concept of "loose
class definitions" that can modify already existing classes. What you
probably want to do is add a preinstall script that saves off the
existing definition (in a global perhaps) and then compiles in the new
definition. You'd also have to restore the original definition in the
postuninstall script. Personally, I'd favour the cleaner approach of
adding globals of the same name.

I hadn't answered this question earlier since it seemed to me that
Chris Uppal's previous post had answered it pretty well.

Best regards

--
Andy Bower
Dolphin Support
www.object-arts.com

>> Blair, what's up with defining extra class variables in Object?
>
> Erm.., nothing AFAIK. Why can't you just define them as normal, i.e.,
> by editing the definition and recompiling. The method comment is just
> warning you not to rename or remove the ones that are already there
> that begin with an underscore. YOu can give them any names you like,
> although preferably not beginning with underscore.

Your explanation is clearer and less alarming than the one in the dialog:  I
stopped the definition because of it.  I see now that it is just a general
warning, but it seemed prohibitive initially.  I tested the new Object
declaration again, chose Ignore (four times), and the definition worked
(after a long wait of about one minute).

>
> You can't, however, add instancve variables to Object.

Understandable.

>
> The major problem will be how to export your change as part of a
> package. The Dolphin package system does not have the concept of "loose
> class definitions" that can modify already existing classes. What you
> probably want to do is add a preinstall script that saves off the
> existing definition (in a global perhaps) and then compiles in the new
> definition. You'd also have to restore the original definition in the
> postuninstall script. Personally, I'd favour the cleaner approach of
> adding globals of the same name.

Using globals instead of Object class variables is simpler for packaging,
but I prefer class-containment of the variables.
>
> I hadn't answered this question earlier since it seemed to me that
> Chris Uppal's previous post had answered it pretty well.

I wanted to declare class variables in the usual way.  I don't recall
whether such declarations were stated to be possible, by anyone, and there
was another post that seemed to imply that it could even be dangerous.  I
suppose the possibility was implied, but the means was roundabout (coded).
This was confusing, and I didn't see why it was necessary.

You answered my questions.  Thanks.


Regards,

Shaping