mmxx-dev Mailing List for MMXX - Modules & Metaclasses ++
Status: Pre-Alpha
Brought to you by:
ljr
Menu
▾
▴
mmxx-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(7) |
May
(8) |
Jun
(5) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: <da...@li...> - 2000-08-13 21:31:39
|
At the very bottom of http://MMXX.sourceforge.net/docs/overview.html there is a link to the FAQ (http://MMXX.sourceforge.net/docs/faq.php), but it's broken. Ciao, -- David N. Welton, Responsabile Progetti Open Source, Linuxcare Italia spa tel +39.049.8043411 fax +39.049.8043412 cel +39.348.2879508 da...@li..., http://www.linuxcare.com/ Linuxcare. Support for the revolution. |
|
From: Frank V. C. <fr...@co...> - 2000-06-21 11:58:43
|
I posted a few weeks ago about a possible conversion of the "mmxxidl" <grin> compiler to using the PCCTS C++ lib. Is activity for MMXX delayed due to the happenstance of life? -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Frank V. C. <fr...@co...> - 2000-06-10 13:57:15
|
I noticed that you are using lex/yacc. There is a OO equivalent (public domain, Unix/Win/Mac) called PCCTS (http://www.antlr.org/pccts133.html). I was playing around with it for a while for OCL constructs in a declarative constraint based system I was getting into (and have since put on the back burner but not because of PCCTS) and it is pretty powerful and flexible. If you want to consider this I would be happy to work on a parallel version of the mmxxsupgen and twentifier utilities. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Frank V. C. <fr...@co...> - 2000-06-08 13:12:38
|
Nice addition with the MMXX pre-processor! I will play around with this neat new addition and provide at least feedback. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Frank V. C. <fr...@co...> - 2000-06-05 02:37:51
|
Sorry for not responding sooner. This is a tough one given the pros and cons for each. I would vote for consistency with the rest of the MMXX metaphor. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux http://PythPat.sourceforge.net Pythons Pattern Package |
|
From: Luca R. <lj...@us...> - 2000-06-01 20:59:49
|
In preparation for 1.0d6, which should hopefully be the last pre-alpha version, there are a couple issues I'd like to get feedback on. The first relates to the exception management model. An initial (unreleased) design did not use the x_exception encapsulator mechanism, but rather called for throwing pointers to MMXXException's and descendants. After having been with the x_exception mechanism for a while, I'm beginning to reconsider whether the pointer-throwing arrangement was not in fact a better solution. Here's a short summary of the pros and cons of each method: Throwing pointers: ----------------- - Simplifies catching: you can catch any MMXXException subclass with precision, and default out to further bases, up to MMXXException* itself. - The biggest drawback is that each and every catch block has responsibility for VirtualDelete()'ing the caught exception. - The second drawback is that users must be careful not to throw or catch the actual types rather than the pointers. - The third drawback is that conceivably, there exist really poor compilers that can't throw/catch pointers well. In particular, if I throw dynamic_cast<BASE*>(p), the compiler needs to be able to catch (DERIVED *p) where BASE and DERIVED are of course polymorphic (though this issue could be worked around if throwing DERIVED*'s works well on all platforms.) Throwing x_exception pointer encapsulators: ------------------------------------------ - Simplifies deleting, as the encapsulator automatically VirtualDelete()'s the exception upon exiting the catch block, unless it was release()'d. Also simplifies type-checking as x_exception will only encapsulate MMXXException's and subclasses. - The biggest drawback is that catch blocks are nasty. Since there's no way for a catch clause to differentiate among the particular encapsulated MMXXException subclass, all the MMXX exceptions must be caught in one catch block, their actual type switch()'ed upon, and any undesired ones re-thrown. - The second drawback is that this arrangement is probably more confusing. - The third drawback is that there are copy-construction issues that could manifest themselves with certain compilers and/or user patterns, as noted in the docs. Some other points: ----------------- - Interestingly enough, since exceptions are always marshalled at boundaries by way of MMXXMetaobject's, it's possible to make both mechanisms available and let the user pick, while maintaining full compatibility with modules written with the other mechanism. However, this just might add more confusion than it adds flexibility. - There are actually third and fourth options, both of which involve deriving from x_exception (perhaps by way of some additional header macros.) In the third option, there's a template class x_texception that derives from x_exception and is parametrized on the class being thrown. That way you can either catch the exact exception in question, or all MMXX exceptions, but you can't catch on a derivation basis, since catch clauses will not use implicit type conversions. The fourth option is to have non-template, yet parametrized xe_* encapsulators whose derivation hierarchy mimics that of the actual classes, e.g. xe_MMXXException encapsulates an MMXXException pointer, xe_MyDerivedException derives from it to encapsulate MyDerivedException pointers and so on. The main drawback with this is that it adds yet another auto-generated class, and is probably no less confusing than any of the other arrangements. What do you think? Luca |
|
From: Frank V. C. <fr...@co...> - 2000-05-10 11:58:08
|
Oh yeah, The terminology suggestions I originally made are the extent of change that I would feel good about. -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-05-04 13:25:00
|
Luca Raggi wrote:
>
> On 5/2/2000 11:11 AM, Frank V. Castellucci (fr...@co...)
> shared his wisdom:
>
> >Have you considered allowing the developer to use a declarative grammar
> >which is then read and the resulting MMXX macro laden header is
> >generated? This has already proven to be quite useful to CORBA
> >developers (IDL grammer), as well as increasing the binding capability
> >for other languages.
>
> Yes, I've considered this. There are a number of interesting
> alternatives, so here's a few points:
>
> 1. It's a significant advantage if such an IDL is not strictly
> *required*, namely because it would require porting a parser to all
> development platforms and would not be instantly compatible with all IDEs
> and the like (on Mac for instance, the Metrowerks IDE has a Plugin API
> whereas MPW uses unix-like commmand line tools, on Windows you'd have
> MSVC which probably has its own plugin API, then there's Cygwin, and so
> on and so forth.) Some users will also see advantages in not having to
> double the number of files involved (.idl and generated .h) and in
> reducing makefile complexity.
Not required. As I said, it would have to emit MMXX laden headers and
module stubs. It is a convenience for the learned, and an entry for the
beginner. It is up to each user if they want to "hand-craft" their MMXX
classes, and there would be nothing to stop them.
> 2. Currently, MMXX headers can utilize type declarations in non-MMXX
> headers (e.g. fragile classes and templates, typedefs, STL declarations.)
> To maintain this property in an IDL parser, we'd either have to make it
> parse all C++ declarations (if we were to strong-check on types) or just
> have it swallow types it knows nothing about. The latter is obviously
> easier and more flexible, however successful parsing of a bad set of
> declarations might induce a false sense of security.
I agree, but by the same token the user is not prevented from adding
arbitrary (and incorrect) type references anywhere. The compiler would
error/warn them at that point.
> 3. I've been able to implement pretty much all the required functionality
> by using the preprocessor and runtime code alone. I view this as an
> advantage in the design phase, in that it's kept me from adopting overly
> sophisticated and intrusive designs (yes it could have been worse! :-)
> that I would have probably opted for had I had all the freedom that comes
> with having a full-blown metacode generating parser. Consider CORBA's C++
> binding for instance: CORBA's language independence at the IDL level
> forced a lot of foreign constructs into CORBA-enabled C++ applications,
> whereas as ugly as MMXX's .h grammar is, the .cpp files do not vary
> tremendously from what one would write without MMXX, with relatively few
> exceptions (i.e. x_ptr<>'s, VirtualDelete(), x_exception's and the likes.)
>
> Most importantly, as you suggested we can still write an IDL parser and
> make it generate macro declarations, enhancing ease of use (particularly
> for first-time users) while maintaining all the advantages above. In
> other words, this thing screams to be disjoint. Also notice that if we
> wait to write one until after the header grammar is finalized, we don't
> have to revise the parser every time we make changes to the header
> grammar.
>
In my most recent involvement in meta class implementation, we used NIH
Class Class with a bunch of macros, in large part reduced to the
implementation requirement of:
DECLARE_CLASS_NIH( SomeName );
class SomeName
{
DECLARE_METHODS_NIH( SomeName );
public:
// ...
};
and in the module
DEFINE_CLASS_NIH( SomeName );
which equiped us with Factories, RTTI (not C++ RTTI), SmartPointers,
etc.
> Once we get to it, here are some interesting alternatives:
> a. Make it parse its own interface definition language.
> b. Make it parse regular C++ declarations, but automatically make MMXX
> adjustments as needed where possible, and produce error messages whenever
> something is incompatible.
> c. Make it parse CORBA's IDL.
>
> Now a. is the relatively easy route to take, since it simplifies the
> parser considerably, and we can just syntax error anything that MMXX
> doesn't support.
Obviously we are strong believers in Meta-data driven function!
> Option b. comes with a really bitchy grammar, but it addresses the issue
> of external type imports (as in 2. above) and is also the easiest for new
> users to deal with.
I believe ANTLR has a C++ grammar already defined, which would make this
much easier, like adding keywords which allowed pass-through statements
for MMXX implemented classes, versus discoverable shadow/proxy methods.
> Option c. is very nice in that it constitutes half the work needed to
> make a MMXX-based CORBA ORB. In the end, both the parser and the ORB
> would be optional add-ons, but it would be pretty cool in that any MMXX
> module could easily become a CORBA server. The biggest problem here is
> that CORBA comes with about a zillion constructs and specs of its own
> that would have to be reconciled at the parser level.
I would stay away from this for now (resources).
> Now if I may digress a bit, option b. is also interesting in that it
> might lay the foundation for a plausible future integration of MMXX
> directly into a C++ compiler, a proposition which is automatically proven
> possible by the fact that a C++ compiler can already generate MMXX
> modules - it just has to be tricked into it. The MMXX facilities could be
> implemented as C++ extensions, and who knows, perhaps even provide some
> suggestions to the standards committee on how to address
> ABI/fragility/reflection issues in the next release of the standard...
One can dream, for now it is a convenience to anyone wanting to get
going with MMXX without a lot of learning. Believe it or not I have
found that there is a large number of developers that are unfamiliar
with meta indirection, and resistence to learning it. Mainly because "I
have enough on my plate. Am I coding C++, fine, don't add alot of new
terms and methodology."
You overcome that by KISS.
--
Frank V. Castellucci
|
|
From: Luca R. <lj...@us...> - 2000-05-02 19:59:27
|
On 5/2/2000 11:11 AM, Frank V. Castellucci (fr...@co...) shared his wisdom: >Have you considered allowing the developer to use a declarative grammar >which is then read and the resulting MMXX macro laden header is >generated? This has already proven to be quite useful to CORBA >developers (IDL grammer), as well as increasing the binding capability >for other languages. Yes, I've considered this. There are a number of interesting alternatives, so here's a few points: 1. It's a significant advantage if such an IDL is not strictly *required*, namely because it would require porting a parser to all development platforms and would not be instantly compatible with all IDEs and the like (on Mac for instance, the Metrowerks IDE has a Plugin API whereas MPW uses unix-like commmand line tools, on Windows you'd have MSVC which probably has its own plugin API, then there's Cygwin, and so on and so forth.) Some users will also see advantages in not having to double the number of files involved (.idl and generated .h) and in reducing makefile complexity. 2. Currently, MMXX headers can utilize type declarations in non-MMXX headers (e.g. fragile classes and templates, typedefs, STL declarations.) To maintain this property in an IDL parser, we'd either have to make it parse all C++ declarations (if we were to strong-check on types) or just have it swallow types it knows nothing about. The latter is obviously easier and more flexible, however successful parsing of a bad set of declarations might induce a false sense of security. 3. I've been able to implement pretty much all the required functionality by using the preprocessor and runtime code alone. I view this as an advantage in the design phase, in that it's kept me from adopting overly sophisticated and intrusive designs (yes it could have been worse! :-) that I would have probably opted for had I had all the freedom that comes with having a full-blown metacode generating parser. Consider CORBA's C++ binding for instance: CORBA's language independence at the IDL level forced a lot of foreign constructs into CORBA-enabled C++ applications, whereas as ugly as MMXX's .h grammar is, the .cpp files do not vary tremendously from what one would write without MMXX, with relatively few exceptions (i.e. x_ptr<>'s, VirtualDelete(), x_exception's and the likes.) Most importantly, as you suggested we can still write an IDL parser and make it generate macro declarations, enhancing ease of use (particularly for first-time users) while maintaining all the advantages above. In other words, this thing screams to be disjoint. Also notice that if we wait to write one until after the header grammar is finalized, we don't have to revise the parser every time we make changes to the header grammar. Once we get to it, here are some interesting alternatives: a. Make it parse its own interface definition language. b. Make it parse regular C++ declarations, but automatically make MMXX adjustments as needed where possible, and produce error messages whenever something is incompatible. c. Make it parse CORBA's IDL. Now a. is the relatively easy route to take, since it simplifies the parser considerably, and we can just syntax error anything that MMXX doesn't support. Option b. comes with a really bitchy grammar, but it addresses the issue of external type imports (as in 2. above) and is also the easiest for new users to deal with. Option c. is very nice in that it constitutes half the work needed to make a MMXX-based CORBA ORB. In the end, both the parser and the ORB would be optional add-ons, but it would be pretty cool in that any MMXX module could easily become a CORBA server. The biggest problem here is that CORBA comes with about a zillion constructs and specs of its own that would have to be reconciled at the parser level. Now if I may digress a bit, option b. is also interesting in that it might lay the foundation for a plausible future integration of MMXX directly into a C++ compiler, a proposition which is automatically proven possible by the fact that a C++ compiler can already generate MMXX modules - it just has to be tricked into it. The MMXX facilities could be implemented as C++ extensions, and who knows, perhaps even provide some suggestions to the standards committee on how to address ABI/fragility/reflection issues in the next release of the standard... Please continue sharing your thoughts as this is very much an open issue. Ciao! Luca |
|
From: Luca R. <lj...@us...> - 2000-05-02 19:57:02
|
On 5/2/2000 10:42 AM, Frank V. Castellucci (fr...@co...) shared his wisdom: >As I said, your call, it's ok by me the way you distribute with the exception >of one thing, if the directory could expand to MMXX-X.Y.Z or whatever release >numbering/identification schema you are using. This way (assuming the >makefiles work off relative locations) testing could occur in the new release >location, and if the user/developer feels good about it they can just rename >the directory. Good idea, absolutely. Will make sure I do it from d5 onwards. >I agree it requires discipline to keep it current, but a notice in the >release notes that something has changed in regards to signatures, method >names, etc. is adequate to let the users know this. Yes, very much so. Once we finalize the various identifier names, we'll adopt some form a Changelog scheme. >Also consider, now being better than later, in using a comment tagging that >is recognized by tools like doc++ or doxygen or whatever. I say now because >you won't have alot of reworking to do. Interesting, I'll have to look into these since I've never used them. >> BTW, if you ask questions here on the list I'd be happy to answer them. >> That way there's a record of at least some of the confusing aspects, and >> the bits and pieces that come through here might become part of a FAQ >> later. > >Err, I assume you were making this statement for the general public as I >thought I posted on the list, neh? Yes, that was intended for everyone, but I also meant to encourage you to ask "dumb" how-does-this-work type questions if it saves you hours of digging through the source code. :-) Ciao! Luca |
|
From: Frank V. C. <fr...@co...> - 2000-05-02 18:09:47
|
Have you considered allowing the developer to use a declarative grammar
which is then read and the resulting MMXX macro laden header is
generated? This has already proven to be quite useful to CORBA
developers (IDL grammer), as well as increasing the binding capability
for other languages.
You have added encodings which are only understandable to the well
trained (You <grin>), and which for the benefit of the project (change,
maintenance, etc) you may want to hide as much as possible from the
implementator.
So in regards to terminology, there need not be any difference from a
class and instance level from the users perspective.
<class>
<identifier> C </identifier>
<inherites>
<parent = public > B </parent>
<parent = protected> A </parent>
</inherits>
<methods>
<constructors>
<accessors>
<mutators>
...
</class>
this (SIMPLIFIED) declaration of class C is all I (as an implementor) is
concerned about making. I'll create the appropriate makefile rules, etc,
etc. to get it into MMXX encodings.
Just a thought,
Frank V. Castellucci
|
|
From: Frank V. C. <fr...@co...> - 2000-05-02 17:41:21
|
Luca Raggi wrote: > On 5/2/2000 7:15 AM, Frank V. Castellucci (fr...@co...) > shared his wisdom: > > >Couple of release points: > > > >I caught some flak over not using the automake, autoconf, and libtool > >release standards. Your call. > > [snip] > This might become a good idea later, i.e. if/when the MMXX support code > itself becomes a MMXX-enabled library, but this is definitely not going > to happen before the ABI settles down to its final form and/or its object > size becomes significant. At the moment isolating the MMXX support code > in a library would actually *increase* overall object size (because we'd > be adding an extra module), and since there's no MMXX libraries out there > yet, for now I think it'd be mostly a headache. > As I said, your call, it's ok by me the way you distribute with the exception of one thing, if the directory could expand to MMXX-X.Y.Z or whatever release numbering/identification schema you are using. This way (assuming the makefiles work off relative locations) testing could occur in the new release location, and if the user/developer feels good about it they can just rename the directory. > > > > >I hate doing it myself, but I beg you: At least provide serious > >documentation in the headers!!! > > > > Hehe yes, you're absolutely right. I've been adding a bit with this > release, unfortunately one problem I've been running into is that as soon > as I comment something, I revise it soon after to make the comment > obsolete, worse yet I tend to forget about having written it which ends > up deceiving the reader! As things stabilize further I will be adding > more. I agree it requires discipline to keep it current, but a notice in the release notes that something has changed in regards to signatures, method names, etc. is adequate to let the users know this. Also consider, now being better than later, in using a comment tagging that is recognized by tools like doc++ or doxygen or whatever. I say now because you won't have alot of reworking to do. > Documentation is really a major issue at this stage, since 90% or so of > the 1.0 features are there, now is about the right time to start focusing > on it. I've extended the "overview" file, I promise I will add to the > "advanced internals" file to cover some of the many missing aspects, but > other than that I'd really need to get some help here. BTW if we're to > revise the terminology, this would be a great time to do that also. Once > those are done, and we get some tutorials and decent test suites, we > could move to Alpha status and start "marketing" to users. My intent was to start focusing on the terminology with the latest download. I just need a bit of time to understand it. Which is why the "doc" points I mentioned appeared, it would make it easier. But hang in there, I will respond within the next few days in regards to terminology. > BTW, if you ask questions here on the list I'd be happy to answer them. > That way there's a record of at least some of the confusing aspects, and > the bits and pieces that come through here might become part of a FAQ > later. Err, I assume you were making this statement for the general public as I thought I posted on the list, neh? > Ciao! > Luca > > _________________ > MMXX-dev: http://lists.sourceforge.net/mailman/listinfo/mmxx-dev |
|
From: Luca R. <lj...@us...> - 2000-05-02 15:35:40
|
On 5/2/2000 7:15 AM, Frank V. Castellucci (fr...@co...) shared his wisdom: >Couple of release points: > >I caught some flak over not using the automake, autoconf, and libtool >release standards. Your call. Yes, well the main issues are that autoconf is not really that "portable" (no Mac/Windows) which complicates things in terms of internal dependencies, and also that since MMXX is currently intended to be included in source form "en toto" in user projects (rather than say, place itself somewhere under /usr/include and the likes and be a project dependency, since again Mac/Windows have no /usr/include) then open source user projects would end up having to use autoconf on un*x even if they don't wish to, and if they already do, they'd have to merge their configure.in's and share their config.h's with MMXX and/or recurse to them and avoid naming conflicts etc. etc. The other thing is that autoconf is very good at isolating unix system dependencies and has a lot of rules for those, but MMXX has very few of those (currently just the standard library stuff and the dlopen() interface.) Its major dependencies are with the compiler's C++ support, which are mostly idiosyncratic in nature, meaning that that they're hard to account for without witnessing them on an individual basis, at which point we know the compiler/version and can just #if it away. This might become a good idea later, i.e. if/when the MMXX support code itself becomes a MMXX-enabled library, but this is definitely not going to happen before the ABI settles down to its final form and/or its object size becomes significant. At the moment isolating the MMXX support code in a library would actually *increase* overall object size (because we'd be adding an extra module), and since there's no MMXX libraries out there yet, for now I think it'd be mostly a headache. > >I hate doing it myself, but I beg you: At least provide serious >documentation in the headers!!! > Hehe yes, you're absolutely right. I've been adding a bit with this release, unfortunately one problem I've been running into is that as soon as I comment something, I revise it soon after to make the comment obsolete, worse yet I tend to forget about having written it which ends up deceiving the reader! As things stabilize further I will be adding more. Documentation is really a major issue at this stage, since 90% or so of the 1.0 features are there, now is about the right time to start focusing on it. I've extended the "overview" file, I promise I will add to the "advanced internals" file to cover some of the many missing aspects, but other than that I'd really need to get some help here. BTW if we're to revise the terminology, this would be a great time to do that also. Once those are done, and we get some tutorials and decent test suites, we could move to Alpha status and start "marketing" to users. Indeed, I've so far refrained from posting in high-visibility places (such as say, comp.lang.c++, mailing lists, etc.) because I was afraid to turn off people who'd come in only to realize there was hardly enough for them to learn to use it without putting in a huge reverse engineering effort. BTW, if you ask questions here on the list I'd be happy to answer them. That way there's a record of at least some of the confusing aspects, and the bits and pieces that come through here might become part of a FAQ later. Ciao! Luca |
|
From: Frank V. C. <fr...@co...> - 2000-05-02 14:23:07
|
Couple of release points: I caught some flak over not using the automake, autoconf, and libtool release standards. Your call. I hate doing it myself, but I beg you: At least provide serious documentation in the headers!!! -- Frank V. Castellucci |
|
From: Frank V. C. <fr...@co...> - 2000-04-21 19:24:20
|
Luca Raggi wrote:
> On 4/21/2000 5:02 AM, Frank V. Castellucci (fr...@co...)
> shared his wisdom:
>
> >Shadow
> >------
> [snip]
> Good point. If you'd be willing to help reengineer the entire vocabulary
> that'd be great. I agree that this has to be done pretty early, since
> changing names gets harder as we go on. Steven has also offered to work on
> the docs/test projects so I'm sure he'll be interested in this :-)
Where are your requirements documents that drove the original grammar?
> My only question on 'proxy' in particular is whether 'proxy' is as
> well-suited as a modifier and verb as it is as a noun, namely because MMXX
> 'shadows' both real classes and other shadows, so in the new terminology
> it'd have to 'proxy' both real classes and other (stacked) proxies. If
> this doesn't abuse 'proxy' as seen in the literature then it's definitely
> a go. Since we're at it, is there a better word for 'peer'? On a
> historical note, i originally picked 'shadow' and 'peer' to get some
> mental
> separation from 'stub class', 'skeleton', etc. as seen elsewhere.
Proxy, by the GoF definition:
Provide a surrogate or placeholder for another object to control access to it.
Which in my view, it is the surrogate role that fits your "shadow" definition.
And now some dictionary references:
prox·y (prks)
n., pl. prox·ies.
1.A person authorized to act for another; an agent or a substitute.
2.The authority to act for another.
3.The written authorization to act in place of another.
n. attributive.
Often used to modify another noun: a proxy vote; proxy troops for a
world power.
Proxy \Prox"y\, v. i. To act or vote by proxy; to do anything by the agency of
another. [R.]
> BTW Frank, I've added you to the developer list on SourceForge
> (however useful that might be at this stage.)
Thats ok, but you realize that besides the full time job I am busy with
CoreLinux++, so I will do the best I can for MMXX.
> Ciao!
> Luca
Frank
|
|
From: Luca R. <lj...@us...> - 2000-04-21 15:06:58
|
On 4/21/2000 5:02 AM, Frank V. Castellucci (fr...@co...) shared his wisdom: >Shadow >------ >The idea of a shadow is, as I am sure you are aware, a Proxy. In the GoF >Patterns, in semantic understanding, etc. Consider changing the >terminology as it would be more familiar than Shadow. Consider other >familiar terms in documentation along the lines of delegation, >marshalling, etc. From a proxy perspective there is also the issues of >performance and scalability to consider. Good point. If you'd be willing to help reengineer the entire vocabulary that'd be great. I agree that this has to be done pretty early, since changing names gets harder as we go on. Steven has also offered to work on the docs/test projects so I'm sure he'll be interested in this :-) However, it'd be nice to 1) make all the needed changes in one shot so that we can keep the development sidetracking to a minimum, and 2) at the same time, adjust most symbol names that need to be adjusted accordingly (and possibly do the overdue syntactical changes too,) since the adv. docs can't 'branch away' from the terminology in the source at this stage. Perhaps we can build a renaming to-do list in a piecemeal fashion? My only question on 'proxy' in particular is whether 'proxy' is as well-suited as a modifier and verb as it is as a noun, namely because MMXX 'shadows' both real classes and other shadows, so in the new terminology it'd have to 'proxy' both real classes and other (stacked) proxies. If this doesn't abuse 'proxy' as seen in the literature then it's definitely a go. Since we're at it, is there a better word for 'peer'? On a historical note, i originally picked 'shadow' and 'peer' to get some mental separation from 'stub class', 'skeleton', etc. as seen elsewhere. I like 'marshall' and 'marshalling' as well, indeed the symbols right now abuse the word 'stub' all over the place mostly because it's short. >I assume that exception management will be delegated back through the >implementation->proxy bridge somehow. Yes, I'm working on adding exception management right now. Exceptions are caught by the callee stub, encapsulated in MMXXException's (if they're not already) and re-thrown by the caller stub. Within a day or so I'm going to post again asking for suggestions about the controversial aspects here, and as I'm sure you've guessed there's quite a few. :) BTW Frank, I've added you to the developer list on SourceForge (however useful that might be at this stage.) Ciao! Luca |
|
From: Frank V. C. <fr...@co...> - 2000-04-21 12:09:27
|
Luca Raggi wrote: > [snip] > > Frank; > > Welcome to the project! Your input and contributions will be greatly > appreciated. I have started to read the docs and existing code. Ok, remember, as always, these are my opinions only: Shadow ------ The idea of a shadow is, as I am sure you are aware, a Proxy. In the GoF Patterns, in semantic understanding, etc. Consider changing the terminology as it would be more familiar than Shadow. Consider other familiar terms in documentation along the lines of delegation, marshalling, etc. From a proxy perspective there is also the issues of performance and scalability to consider. I assume that exception management will be delegated back through the implementation->proxy bridge somehow. > [snip] -- Frank V. Castellucci |
|
From: Luca R. <lj...@us...> - 2000-04-19 23:08:50
|
On 4/19/2000 3:00 PM, Frank V. Castellucci (fr...@co...) shared his wisdom: >Hello MMXX'ers > >I am interested in this project for two reasons: > >1. I have been working extensively with meta-model driven applications >and reasoning systems over the past five years. >2. And, as the signature indicates, have a C++ class library project in >the works. Frank; Welcome to the project! Your input and contributions will be greatly appreciated. > >The first being useful if I may help by providing input based on >experience and mistakes (more of the latter than the former) This is indeed one of the most urgent tasks - scrutinizing MMXX's APIs, internal methodologies and overall design to improve quality, generality and strength. I hope that the development-level docs in the distribution will be enough for you to familiarize yourself with it. Devt-level docs are a high priority and I plan to release more soon. > and the >second because I am up against a problem in the class library >implementation that I perceive only a type ontology can solve. > >So, if this project gets moving along (can I assume it is LGPL), and it >provides something that would save my time I would like to potentially >drive some requirements. The metaclass (i.e. ontology) API is another area in need of work and that you might be interested in contributing to, since it sounds closely related to what you need for your project and have been working on. The current APIs are highly preliminary: thus far the focus has been on addressing the fragile base class problem, that is to say the "Modules" part of the MMXX acronym. Best Regards, Luca Raggi |
|
From: Frank V. C. <fr...@co...> - 2000-04-19 22:07:55
|
Hello MMXX'ers I am interested in this project for two reasons: 1. I have been working extensively with meta-model driven applications and reasoning systems over the past five years. 2. And, as the signature indicates, have a C++ class library project in the works. The first being useful if I may help by providing input based on experience and mistakes (more of the latter than the former), and the second because I am up against a problem in the class library implementation that I perceive only a type ontology can solve. So, if this project gets moving along (can I assume it is LGPL), and it provides something that would save my time I would like to potentially drive some requirements. -- Frank V. Castellucci http://corelinux.sourceforge.net OOA/OOD/C++ Standards and Guidelines for Linux |
|
From: Luca R. <lj...@us...> - 2000-04-17 20:52:15
|
Test post. |
|
From: Luca R. <lj...@us...> - 2000-04-17 20:35:52
|
Test post. |
