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!
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" tapplek@gmail.com 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.
On Thu, Nov 15, 2007 at 08:40:36PM -0600, itsme213 wrote:
"Matthew Fulmer" tapplek@gmail.com 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:
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.
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 -
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
"Matthew Fulmer" tapplek@gmail.com 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
On Fri, Nov 16, 2007 at 08:36:22AM -0600, itsme213 wrote:
"Matthew Fulmer" tapplek@gmail.com 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.
On Fri, Nov 16, 2007 at 09:08:02AM -0700, Matthew Fulmer wrote:
On Fri, Nov 16, 2007 at 08:36:22AM -0600, itsme213 wrote:
Traits might solve some of this, but I don't think I want to be that much on the 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.
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.
beginners@lists.squeakfoundation.org
-
Bert Freudenberg -
itsme213 -
Keith Hodges -
Matthew Fulmer