ctms-devel — Development

[Ctms-devel] Re: Source forge updated

[Steve W. <sw...@oz...>]

Hi All,

Catching up on my inbox ..

> "strongtalk" has been released.  I have not completely read
> over the new specification, but we may get some ideas from
> it for future Camp Smalltalk work.

Have you had a chance to look more closely at Strongtalk? I spent some time
this weekend playing with it, and its Type System is very impressive. I see
CTMS as having different goals, but it is interesting to study Strongtalk's
comprehensive approach to typing Smalltalk. My understanding is that its
Type System (in principle at least) is portable, but to be useful the type
information would need to be added to base classes.

Have you been using CTMS?

I have not had the chance to work on CTMS itself, as I have been working on
an implementation of the client side of the WebDAV protocol this week. It
involves some simple xml (de/)serialization. At one point I did experiment
with using CTMS to provide the metadata for the serialization, the idea
being to map between a Smalltalk typegroup and a typegroup describing the
xml elements. I ended up abandoning the approach as I needed to make
progress on the WebDAV project and I really only needed something simple :)

> " Your note had the method below as a class method of CtmTypeGroup, but I
> suspect that it is really an instance method? "

Yes, typo in the message.

> A few other methods.    Are these dialect/implementation-specific?  Should
> they be API?
> #ctmTypeGroupDefault  or #ctmSmalltalkTypeGroup  -  returns the
"Smalltalk"
> type group
> #ctmTypeSpecification  - resolves the receiver's type from the default
type
> group

Sure, is the idea to have a cached instance of the "Smalltalk" type group?
The only problem I can see is that the user would need to rebuild it when
definitions change.

>  Perhaps we should lazy-initialize the #properties attribute
> since the majority of type descriptions won't use it.
> Creation of Dictionary objects can be unnecessarily expensive.

Sure ... FWIW: Dolphin has a built-in property system, any instance can have
a property dictionary which is itself lazily initialized. We would probably
make use of this in the Dolphin version, but it would be nice to have
specific "ctm" accessors to make it clear that the intention is to give the
user the opportunity to extend the system with their own metadata.

>  New question...
> Should our API include instance methods for requesting and initializing a
> CtmTypeSpecification?
> This would allow for dynamic construction of type specifications based
upon
> dynamic conditions.  For example, a database row schema could be
> "described" at runtime by the database and a CtmTypeSpecification could be
> derived from the database row description.  Should there be instance-based
> protocol that is consistent with the class methods defined above?

This is interesting, while I dont have experience with your example, In
Spray, for certain Collection classes, I do treat instances as different
types. So yes, I would find an API that specifies types by either class or
instance to be useful.

Steve
sw...@oz...
http://www.dolphinharbor.org

[Ctms-devel] Re: Source forge updated

[<br...@us...>]

Steve,

So far, I have not tried to download your changes from Sourceforge (nor the
SstInsurance.zip that you referenced).  I hope the Sourceforge problems
that you were experiencing have been solved.  I clipped out some of the
questions from the swUseCases.rtf file in your note.  Below is some
feedback.  I will have a look at your changes and demo in the near future.

>> Should there be one (and only one) CtmTypeSpecification for a Smalltalk
class?
>> The only circumstance I can think of, where a user would need multiple
specifications, is to support different versions of the same Class.
>> Am I missing something?

To me, it seems logical that each class has only one CtmTypeSpecification.
I suppose that you could define multiple type specifications for exposure
to different sets of users; however, this seems outside the scope of what
we are trying to accomplish.   For example, you might supply one
CtmTypeSpecification that contains the entire interface of a class (for
internal usage) and another CtmTypeSpecification that contains a subset of
the interface (for external usage).  I think our CtmTypeSystem can already
support this unlikely usage scenario.



>> Should we have an API so that a class-side method contains the CTMS
"Smalltalk"  typeGroup information?
Yes.  This seems like a flexible approach.

NOTE:  The two methods from my note (#ctmTypeSpecification and
#ctmTypeSpecificationIn: ) were intended to be getter methods to derive a
type specification for class.  My suggested API did not include provision
for initialization/construction of types.

Below is a consolidated API derived from information in both of our
notes...

Class methods (default implementation in Object class)
#addCtmTypeSpecificationTo: aCtmGroup  " add the type to @aCtmGroup "
#ctmTypeSpecificationFrom: aCtmGroup   " (formerly ctmTypeSpecificationIn:)
get the type from @aCtmGroup "

" Your note had the method below as a class method of CtmTypeGroup, but I
suspect that it is really an instance method? "
CtmTypeGroup>>#addCtmTypeSpecificationFor: aClass


A few other methods.    Are these dialect/implementation-specific?  Should
they be API?
#ctmTypeGroupDefault  or #ctmSmalltalkTypeGroup  -  returns the "Smalltalk"
type group
#ctmTypeSpecification  - resolves the receiver's type from the default type
group


>> Should CtmSpecifications have properties that can be used to extend the
"base" information?
Yes.  This seems like a good idea.  Users could provide additional
information about the type without needing to create new subclasses of
CtmType.
Perhaps we should lazy-initialize the #properties attribute since the
majority of type descriptions won't use it.  Creation of Dictionary objects
can be unnecessarily expensive.


 New question...
Should our API include instance methods for requesting and initializing a
CtmTypeSpecification?
This would allow for dynamic construction of type specifications based upon
dynamic conditions.  For example, a database row schema could be
"described" at runtime by the database and a CtmTypeSpecification could be
derived from the database row description.  Should there be instance-based
protocol that is consistent with the class methods defined above?

[Ctms-devel] Strongtalk 1.1

[<br...@us...>]

Hello CTMS gang,

"strongtalk" has been released.  I have not completely read over the new
specification, but we may get some ideas from it for future Camp Smalltalk
work.


Strongtalk 1.1 - Release Date: July 1, 2002

http://www.cs.ucsb.edu/projects/strongtalk/

[Ctms-devel] Re: Source forge updated

[Steve W. <sw...@oz...>]

Hi,

Is everyone subscribed to the ctm...@li... list?

> but it was sent to a moderator

... The moderator was fast asleep :)

Bryan, the changes and the ctms1.doc look great!

I have attached some use notes, and commited a few minor changes;

Changes:
 - Implemented more of the #mapTo: methods.
 - Changed use of Atoms? to Symbols. The use of the literal ##unbounded is
not dialect neutral. Is there a problem with using Symbols?
 - Added a "InsExampleDefinitions" module (see attached notes).

CVS Stuff up :(
 - I started by adding a "InsuranceDefinitions" module. In the middle of a
commit my cvs client crashed (I had failed to include the -m parameter).
This has left a lock in that directory. The sourceforge documentation states
that I would need to send them an email to remove this lock. I am waiting "a
reasonable amount of time " to see if it removes itself. Can the directory
be deleted?

Steve
sw...@oz...
http://www.dolphinharbor.org