Clamato roadmap
abbat
environment including:
- inspector tools;
- class browser with advanced navigation and methods protocol support;
- basic refactoring (renaming of classes, methods, instance variables,
pushing methods to superclass)
- namespaces support (it is important for creating really complex web
applications)
I suspect, debugger is needless.
Some other desirable features:
- comments syntax support ( I suggest some realization at this:
http://sites.google.com/site/abbatfilestore/clamato/cookbook/commentssupport
)
- explicit return support (I suggest some realization at this:
http://sites.google.com/site/abbatfilestore/clamato/cookbook/explicitconditionalreturnsupport
)
- syntax for Array creating
- compile time evaluations (
http://web.archive.org/web/20050309223424/www.smalltalkchronicles.net/edition2-1/st_compiler.htm
).
Please discuss.
Avi Bryant
>
> For me, main clamato target is building complete Smalltalk-like
> environment including:
> - inspector tools;
Agreed...
> - class browser with advanced navigation and methods protocol support;
Can you elaborate on this?
> - basic refactoring (renaming of classes, methods, instance variables,
> pushing methods to superclass)
Agreed.
> - namespaces support (it is important for creating really complex web
> applications)
I'm of two minds here. Yes, namespacing is valuable, but it also adds
a complexity cost, and I'm not totally convinced it's worthwhile.
Squeak and Objective-C have done pretty well without formal
namespaces, and it may be that clamato can too.
> I suspect, debugger is needless.
A debugger would be great but very difficult; we don't have access to
the structures we need (without going outside of the standard JS
runtime, anyway). Certainly doesn't seem like it should be on the
short term roadmap.
> Some other desirable features:
> - comments syntax support ( I suggest some realization at this:
> http://sites.google.com/site/abbatfilestore/clamato/cookbook/commentssupport )
> - explicit return support (I suggest some realization at this:
> http://sites.google.com/site/abbatfilestore/clamato/cookbook/explicitconditionalreturnsupport
> )
In both of these cases I'm somewhat sympathetic to the goal but not
sold on the exact implementation.
> - syntax for Array creating
I think that, given that we're in Javscript-land, JSON may be the most
sensible kind of array literal to support. For static literals this
would be easy... you could maybe just prefix with a hash and then have
standard JSON syntax, eg #[1,2,3] or #{"foo": "bar"}. You would
*maybe* want to allow escaping back into Smalltalk with, say, #(), but
that might get too messy.
> - compile time evaluations (
> http://web.archive.org/web/20050309223424/www.smalltalkchronicles.net/edition2-1/st_compiler.htm
I'm not sure why I'd want compile time evaluation. Example?
Avi
abbat
> I'm not sure why I'd want compile time evaluation. Example?
- foo
| a |
...
a := Array with: 1 with: 1. "some relative complicated constant (in
terms of object using) construction"
...
In each sending of "foo" will be evaluated pointed expression.
So, it is obvious performance loss.
Possible solutions:
1. Hold this value in instance varible.
Defects:
- unwanted copy of this value in each object instance;
- clogging list of instance variables;
- not work in object initialization methods.
2. Hold this value in class instance varible or special objects cache.
Also not very beautiful solution: it is demand solve local problem for
account of global abstractions.
(Sorry for my English)