monticello package - adding instance variables to existing classes

I understand how Monticello deals with me adding (in my package) some
methods to an existing class like Object (from other package).

How does it deal with me adding an instance variable?

Thanks!



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Thu, Nov 15, 2007 at 07:50:54PM -0600, itsme213 wrote:
> I understand how Monticello deals with me adding (in my package) some
> methods to an existing class like Object (from other package).
>
> How does it deal with me adding an instance variable?

If you mean in a class outside you're package, it doesn't

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

"Matthew Fulmer" <[hidden email]> wrote in message
> On Thu, Nov 15, 2007 at 07:50:54PM -0600, itsme213 wrote:
>> I understand how Monticello deals with me adding (in my package) some
>> methods to an existing class like Object (from other package).
>>
>> How does it deal with me adding an instance variable?
>
> If you mean in a class outside you're package, it doesn't

Does that mean I cannot (or am not supposed to) add inst-vars to existing
classes homed in other packages? I was hoping that doing this, and adding
lazy initializing accessors, would allow for an aop-style definition of some
classes. Class even has a method #addInstVarName:

I am curious about the reasons for this restriction. Is it because of the
way Monticello relies on method category names?

Thanks.



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Thu, Nov 15, 2007 at 08:40:36PM -0600, itsme213 wrote:
As a feature/hack (depending on your point of view), many
classes (most seaside classes and all morphs) sport a property
dictionary and accessors like propertyAt: propertyAt:put:, and
propertyAt:ifAbsent:, which can do lazy initialization of custom
data. If you are using such a class, you're in luck.

What are you trying to do, exactly?

> I am curious about the reasons for this restriction. Is it because of the
> way Monticello relies on method category names?

For the most part, this is the reason for the restriction. I
would consider it a bug.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Nov 16, 2007, at 4:34 , Matthew Fulmer wrote:
>
>> I am curious about the reasons for this restriction. Is it because  
>> of the
>> way Monticello relies on method category names?
>
> For the most part, this is the reason for the restriction. I
> would consider it a bug.

More like a missing feature, but not necessarily in MC. We have  
simply no way of annotating which inst var belongs to which package.  
If the system and PackageInfo was extended to allow this annotation,  
then MC could be made to use it.

Both MC2 and DeltaStreams deal with this.

For plain MC you can hack around it with the meta sword, as usual.

- Bert -


_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

"Matthew Fulmer" <[hidden email]> wrote in message
> What are you trying to do, exactly?

Currently just experimenting to decide some architectural choices, one of
which would define some of my classes in an aspect-oriented style: different
aspects of overlapping classes -- including i-vars -- defined in different
packages. Going to property dictionaries would give up too much other stuff.

Traits might solve some of this, but I don't think I want to be that much on
the bleeding edge ...

Thanks,
Sophie



_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Fri, Nov 16, 2007 at 08:36:22AM -0600, itsme213 wrote:
>
> "Matthew Fulmer" <[hidden email]> wrote in message
> > What are you trying to do, exactly?
>
> Currently just experimenting to decide some architectural choices, one of
> which would define some of my classes in an aspect-oriented style: different
> aspects of overlapping classes -- including i-vars -- defined in different
> packages. Going to property dictionaries would give up too much other stuff.

That doesn't really answer my question, but...

The usual way to develop in squeak is to build something that
mostly works, and you will discover along the way what you need
to refactor. I read Aspect Oriented Programming at Wikipedia,
since I don't really know what you are talking about. It looked
like it is primarily concerned with implementing functionality
across a set of objects. This is the purpose of the decorator
pattern, which Pier is based on, and is now also finding it's
way into Seaside via Keith Hodges' plugins.

Again, what are you building?

> Traits might solve some of this, but I don't think I want to be that much on
> the bleeding edge ...

Traits aren't bleeding edge; they've been in the stable release
for a year now. Namespaces, spoon, and SecureSqueak are more
what I call bleeding edge.

Traits don't seem to me to be related to the security example
used at the Wikipedia entry on AOP. That is specifically
designed to intercept and provide pluggable processing of
messages. For instance, Pier Unix security is just a decorator
added to each document in the pier document hierarchy that
assigns permissions for actions.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

On Fri, Nov 16, 2007 at 09:08:02AM -0700, Matthew Fulmer wrote:
Traits, on the other hand, are for suplementing the class
heiarchy with shared behavior. They do nothing about per-object
state and behavior, which seems more what you want.

--
Matthew Fulmer -- http://mtfulmer.wordpress.com/
Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808
_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners

 
>>
>> For the most part, this is the reason for the restriction. I
>> would consider it a bug.
>   <snipped>
>
> For plain MC you can hack around it with the meta sword, as usual.
>
> - Bert -
Yes indeed a missing feature.

MC1.5 has hooks for it, you define a methods prefixed #mcInstall /
#mcUninstall #mcAfterInstall / #mcAfterRemoval

e.g.

SomeoneElsesClass-mcOnInstallAddVarNewVarName: aClassEditor {
*mypackagecategory }

"This code gets run on installing the package before the new package is
committed to the image.
In the method you are passed the class to which you can make any changes
you wish. e.g."

aClassEditor addInstVarName: 'bob'

....

Unfortunately however these hooks were designed to be used with the new
SystemEditor based atomic loading scheme, and does not work out of the
box with the current release.

However you have just inspired me fix that so.. use at your own risk.

MC1.5 with these hooks enabled is in http://mc.squeaksource.com/mc

best regards

Keith








_______________________________________________
Beginners mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/beginners