One benefit of a framework like EMF in Java is that i provides a
higher-level implementation of relationships between model elements. It
is possible, for instance, to define uni-/bi-directional,
single-/multi-value and containment relationships that are properly
managed by the framework (e.g. properly maintaining both ends of a
bi-directional relationship when any of the two ends change, or
propagating notifications when object properties change).
Does CLOS provides that functionality out of the box? Or are there
packages that achieve the same?
What about validation or rules on top of that model?
thanks in advance!
On 10 Jul 2006 16:45:23 -0700, "Lemon" <······@gmail.com> wrote:
>
> One benefit of a framework like EMF in Java is that i provides a
> higher-level implementation of relationships between model elements. It
> is possible, for instance, to define uni-/bi-directional,
> single-/multi-value and containment relationships that are properly
> managed by the framework (e.g. properly maintaining both ends of a
> bi-directional relationship when any of the two ends change, or
> propagating notifications when object properties change).
>
> Does CLOS provides that functionality out of the box? Or are there
> packages that achieve the same?
> What about validation or rules on top of that model?
>
> thanks in advance!
Ken Tilton can explain the benefits of Cells[1], but I would also
like to point out that two other features of EMF, that being
serialization as an intrinsic concept of the framework and
explicit support for building modeling tools, are not available
out of the box with Cells.
I haven't researched other Lisp-based dataflow/dependency
packages, so I can't help much more than that.
--
Jack Unrue
[1] http://common-lisp.net/project/cells/
On Tue, 11 Jul 2006 00:29:39 GMT, Jack Unrue <·······@example.tld> wrote:
>
>On 10 Jul 2006 16:45:23 -0700, "Lemon" <······@gmail.com> wrote:
>>
>> One benefit of a framework like EMF in Java is that i provides a
>> higher-level implementation of relationships between model elements. It
>> is possible, for instance, to define uni-/bi-directional,
>> single-/multi-value and containment relationships that are properly
>> managed by the framework (e.g. properly maintaining both ends of a
>> bi-directional relationship when any of the two ends change, or
>> propagating notifications when object properties change).
>>
>> Does CLOS provides that functionality out of the box? Or are there
>> packages that achieve the same?
>> What about validation or rules on top of that model?
>>
>> thanks in advance!
>
>Ken Tilton can explain the benefits of Cells[1], but I would also
>like to point out that two other features of EMF, that being
>serialization as an intrinsic concept of the framework and
>explicit support for building modeling tools, are not available
>out of the box with Cells.
Or CLOS for that matter. And to be clear, I'm not talking about
simple object persistence. I'm talking about model change logging
and constraint validation, like you have with SDO (the object
model used with EMF).
--
Jack Unrue
From: Ken Tilton
Subject: Re: Relationships between objects in CLOS
Date:
Message-ID: <S4Fsg.59$%L7.12@fe10.lga>
Jack Unrue wrote:
> On Tue, 11 Jul 2006 00:29:39 GMT, Jack Unrue <·······@example.tld> wrote:
>
>>On 10 Jul 2006 16:45:23 -0700, "Lemon" <······@gmail.com> wrote:
>>
>>>One benefit of a framework like EMF in Java is that i provides a
>>>higher-level implementation of relationships between model elements. It
>>>is possible, for instance, to define uni-/bi-directional,
>>>single-/multi-value and containment relationships that are properly
>>>managed by the framework (e.g. properly maintaining both ends of a
>>>bi-directional relationship when any of the two ends change, or
>>>propagating notifications when object properties change).
>>>
>>>Does CLOS provides that functionality out of the box? Or are there
>>>packages that achieve the same?
>>>What about validation or rules on top of that model?
>>>
>>>thanks in advance!
>>
>>Ken Tilton can explain the benefits of Cells[1], but I would also
>>like to point out that two other features of EMF, that being
>>serialization as an intrinsic concept of the framework and
>>explicit support for building modeling tools, are not available
>>out of the box with Cells.
Sorry, I looked at some introductory material on EMF and I have no clue
what it does. But at least now I understand why Bradshaw loses it so
badly when he talks about Java. It is a funny kind of way for
programming to die... death by obsucation or something. Absolutely
painful to look at. Not as bad as all those parentheses, of course.
Btw, watch the Cells list for word on serialization, we kicked that
effort off yesterday.
As for "exlicit support for building modelling tools"...ewwww. Cells
gives you explicit support for programming applications. Without
modelling tools. Well, to be precise, Lisp is the modelling tool. Like
Graham said, you can figure out whatyou are doing over the keyboard.
kt
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
Following are some features I use from EMF. I dont care much about
Java, EMF or MOF per se and I am by no means preaching them here, but I
do care about the high level and concrete benefits that a framework
like EMF brings to building real applications:
- EMF provides an infrastructure to use model in a Java application.
- Based on OMG's MOF: abstract language and framework for specifying,
constructing, and managing technology neutral metamodels
- Various Eclipse projects are relying on EMF to create models
- Notification framework: there is a well defined API for being
notified about state changes in EMF object attributes/references (i.e.
slots).
- Serialization framework: create your models in EMF and you
automatically serialize them to XMI or a custom schema. Proxy
resolution and demand loading framework. At least two projects I know
of are working on a framework that can automatically persist your
models to a relational database.
- Reflexive API and Dynamic model definition: create and introspect
models dynamically
- Bidirectional reference handshaking: both end of the relationship are
always kept in sync
- Simple models constraints on objects and relationships
- Tracking modifications
- Validation framework
Is Cell the answer in the CLISP world for the features above? Or are
CLISPers building some of these mechanisms by hand for each new
application?
-- ydw
Ken Tilton wrote:
> Jack Unrue wrote:
> > On Tue, 11 Jul 2006 00:29:39 GMT, Jack Unrue <·······@example.tld> wrote:
> >
> >>On 10 Jul 2006 16:45:23 -0700, "Lemon" <······@gmail.com> wrote:
> >>
> >>>One benefit of a framework like EMF in Java is that i provides a
> >>>higher-level implementation of relationships between model elements. It
> >>>is possible, for instance, to define uni-/bi-directional,
> >>>single-/multi-value and containment relationships that are properly
> >>>managed by the framework (e.g. properly maintaining both ends of a
> >>>bi-directional relationship when any of the two ends change, or
> >>>propagating notifications when object properties change).
> >>>
> >>>Does CLOS provides that functionality out of the box? Or are there
> >>>packages that achieve the same?
> >>>What about validation or rules on top of that model?
> >>>
> >>>thanks in advance!
> >>
> >>Ken Tilton can explain the benefits of Cells[1], but I would also
> >>like to point out that two other features of EMF, that being
> >>serialization as an intrinsic concept of the framework and
> >>explicit support for building modeling tools, are not available
> >>out of the box with Cells.
>
> Sorry, I looked at some introductory material on EMF and I have no clue
> what it does. But at least now I understand why Bradshaw loses it so
> badly when he talks about Java. It is a funny kind of way for
> programming to die... death by obsucation or something. Absolutely
> painful to look at. Not as bad as all those parentheses, of course.
>
> Btw, watch the Cells list for word on serialization, we kicked that
> effort off yesterday.
>
> As for "exlicit support for building modelling tools"...ewwww. Cells
> gives you explicit support for programming applications. Without
> modelling tools. Well, to be precise, Lisp is the modelling tool. Like
> Graham said, you can figure out whatyou are doing over the keyboard.
>
> kt
>
> --
> Cells: http://common-lisp.net/project/cells/
>
> "I'll say I'm losing my grip, and it feels terrific."
> -- Smiling husband to scowling wife, New Yorker cartoon
From: Ken Tilton
Subject: Re: Relationships between objects in CLOS
Date:
Message-ID: <s3Isg.58$yS1.38@fe09.lga>
Point of information: "model" to me is a rather general and abstract
word which seems to be used below as if it has a very specific meaning.
Yes? No? Are we talking about UML or something? is the big win the bit
about "technology neutral"?
I build models out of CLOS. I persist with AllegroStore or Rucksack or
cl-xml or print/read. I use Cells to connect everything. I do not use a
second language from which Lisp is generated, and indeed this "model
building" is Just Programming.
As with AOP, EMF just sounds like another measure of how hard it is to
develop big, complex systems with a fundamentally primitive and broken
language like Java.
Lemon wrote:
> Following are some features I use from EMF. I dont care much about
> Java, EMF or MOF per se and I am by no means preaching them here, but I
> do care about the high level and concrete benefits that a framework
> like EMF brings to building real applications:
Well of course a good Lisp programmer works at a terrifically high level
thanks to macros and reflection and CLOS etc etc etc. I think the
culture clash is the very idea of looking for EMF (as in a distinct tool
to be learned) in Lisp when Lisp /is/ EMF.
>
> - EMF provides an infrastructure to use model in a Java application.
> - Based on OMG's MOF: abstract language and framework for specifying,
> constructing, and managing technology neutral metamodels
Neutrality? I want to bury other languages, not have a gateway to them.
> - Various Eclipse projects are relying on EMF to create models
> - Notification framework: there is a well defined API for being
> notified about state changes in EMF object attributes/references (i.e.
> slots).
This is where Cells would come in.
> - Serialization framework: create your models in EMF and you
> automatically serialize them to XMI or a custom schema. Proxy
> resolution and demand loading framework. At least two projects I know
> of are working on a framework that can automatically persist your
> models to a relational database.
Here again I would hold out for persistent CLOS and avoid the ugliness
and hassle of changing my representation merely to persist.
> - Reflexive API and Dynamic model definition: create and introspect
> models dynamically
Beyond the Java reflection package?
> - Bidirectional reference handshaking: both end of the relationship are
> always kept in sync
> - Simple models constraints on objects and relationships
> - Tracking modifications
Cells again.
> - Validation framework
Would that be the Lisp compiler?
>
> Is Cell the answer in the CLISP world for the features above? Or are
> CLISPers building some of these mechanisms by hand for each new
> application?
Note: CLisp is actually the name of a specific implementation of CL or
Common Lisp.
Cells is used by like three people besides me. The Pythonistas seem more
enthusiastic, and you might check out Philip Eby's stuff in Python. last
I heard he had adopted Cells (his own hack of the same basic
algorithm) for his own enterprise software.
As for what CLers do, I have tried to explain above. You might also dig
into paul graham's copious writing. It sounds to me as if the
"dumb-it-down" design decisions of java make it impossible to ideate at
a sufficiently high level of abstraction in the code itself, so in a
sense one is always staring at the disassembly of one's intent. No
macros, not even a preprocessor. No generic functions, no multiple
inheritance, strong static typing -- no wonder no one wants to use it
for modelling over the keyboard.
If I understand what you mean by "model". :)
kenny
From: Ken
Subject: Re: Relationships between objects in CLOS
Date:
Message-ID: <g6Jsg.2$1h5.1@fe12.lga>
uh-oh, the memory is going:
http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/8b24ab8bb3ccc4ec/6f618f83381af16a?lnk=st&q=emf+MOP&rnum=1#6f618f83381af16a
That was a 3/10/2006 discussion of EMF vis a vis Cells. :)
kenny
Ken Tilton wrote:
> Point of information: "model" to me is a rather general and abstract
> word which seems to be used below as if it has a very specific meaning.
> Yes? No? Are we talking about UML or something? is the big win the bit
> about "technology neutral"?
>
It is indeed an overused term, but I was not using it in the UMLstract
sense. If I am building a bloggling app, my app will need to manipulate
domain concepts like blogs, posts, comments, etc (e.g. create a new
post and associate it with Joe's blog, find specific comments, change
properties of posts, etc). That is the sense of model I was implying:
very concrete and dealt with at a programming level.
>
> I build models out of CLOS. I persist with AllegroStore or Rucksack or
> cl-xml or print/read. I use Cells to connect everything. I do not use a
> second language from which Lisp is generated, and indeed this "model
> building" is Just Programming.
>
> As with AOP, EMF just sounds like another measure of how hard it is to
> develop big, complex systems with a fundamentally primitive and broken
> language like Java.
>
I agree to some extent. I agree that Java as a language leaves a lot to
be desired and makes the job of a programmer harder. That may increase
the appeal of using something like EMF in the Java world, but even so,
there are features in EMF that go beyound event to what CL and CLOS
support out of the box. One example is the need to implement something
like Cells in CL (if I understood its general idea correctly).
I am a first hand witness of how one has to integrate a varied of
different libraries and frameworks in order to get an implementation
done in Java. I imagine that is still true in CL, but maybe to a small
degree because the language provides the flexibility needed to remove
all the unneeded crap and hide what the programmer shouldnt be dealing
with.
>
> Lemon wrote:
> > Following are some features I use from EMF. I dont care much about
> > Java, EMF or MOF per se and I am by no means preaching them here, but I
> > do care about the high level and concrete benefits that a framework
> > like EMF brings to building real applications:
>
> Well of course a good Lisp programmer works at a terrifically high level
> thanks to macros and reflection and CLOS etc etc etc. I think the
> culture clash is the very idea of looking for EMF (as in a distinct tool
> to be learned) in Lisp when Lisp /is/ EMF.
>
I can see that to some extent as I mentioned above. CL didnt preclude
the need to create Cells, for instance. On the other hand, I can also
see that a lot of the value and design decisions in EMF where driven by
Java's limitations. EMF takes a lot of the pain out of the programmer
when writing consistent models in Java, but surely adds a bunch of
other pains to the mix.
One of my goals re: CL is understand the pains it removes and the pains
it adds; gauge what have I been missing all these years building
applications in Java. And representing domain models in CL is one
focus.
> >
> > - EMF provides an infrastructure to use model in a Java application.
> > - Based on OMG's MOF: abstract language and framework for specifying,
> > constructing, and managing technology neutral metamodels
>
> Neutrality? I want to bury other languages, not have a gateway to them.
>
I consider the above MOF's goal at a larger scope than the programming
level we have been talking about here. The world is not just CL or Java
and the fact that the models can be described at a meta-model level
means that I can share models between CL and Java: both instances of
the models but also the models themselves. MOF is a meta-model
(circular) that allows one to describe domain models. It is a small
subset of UML. XMI is just an XML representation of anything produced
by MOF instances being them domain models or their domain model
instances. However, I prefer not to emphasize that since it is a can or
worms...
> > - Various Eclipse projects are relying on EMF to create models
> > - Notification framework: there is a well defined API for being
> > notified about state changes in EMF object attributes/references (i.e.
> > slots).
>
> This is where Cells would come in.
>
In my first read of Cells, I got the impressions that it allows one to
create calculated slots only, but it seems that it can do more than
that. I'll take a deeper look. Can I consider the docs in the Cell
project site the main source? Or are there other documents I should be
aware of?
> > - Serialization framework: create your models in EMF and you
> > automatically serialize them to XMI or a custom schema. Proxy
> > resolution and demand loading framework. At least two projects I know
> > of are working on a framework that can automatically persist your
> > models to a relational database.
>
> Here again I would hold out for persistent CLOS and avoid the ugliness
> and hassle of changing my representation merely to persist.
>
> > - Reflexive API and Dynamic model definition: create and introspect
> > models dynamically
>
> Beyond the Java reflection package?
>
Yes. I am able to reflect at the domain model level. However, I have to
use a generic API to do that (I can hear already the "arghhh" in the
crowd ... :-)).
> > - Bidirectional reference handshaking: both end of the relationship are
> > always kept in sync
> > - Simple models constraints on objects and relationships
> > - Tracking modifications
>
> Cells again.
>
Ok, I'll definetely have to read on Cells.
> > - Validation framework
>
> Would that be the Lisp compiler?
>
:-) Can the List compiler guarantee or at least validate that blog
posts cannot have more than 100 comments? Or that an employee cannot be
its own employer?
> >
> > Is Cell the answer in the CLISP world for the features above? Or are
> > CLISPers building some of these mechanisms by hand for each new
> > application?
>
> Note: CLisp is actually the name of a specific implementation of CL or
> Common Lisp.
thanks for the correction.
>
> Cells is used by like three people besides me. The Pythonistas seem more
> enthusiastic, and you might check out Philip Eby's stuff in Python. last
> I heard he had adopted Cells (his own hack of the same basic
> algorithm) for his own enterprise software.
>
> As for what CLers do, I have tried to explain above. You might also dig
> into paul graham's copious writing. It sounds to me as if the
> "dumb-it-down" design decisions of java make it impossible to ideate at
> a sufficiently high level of abstraction in the code itself, so in a
> sense one is always staring at the disassembly of one's intent. No
> macros, not even a preprocessor. No generic functions, no multiple
> inheritance, strong static typing -- no wonder no one wants to use it
> for modelling over the keyboard.
>
> If I understand what you mean by "model". :)
>
Thanks for your detailed response. My journey into CL is just
starting...
> kenny
-- yuri
Lemon wrote:
> If I am building a bloggling app, my app will need to manipulate
> domain concepts like blogs, posts, comments, etc (e.g. create a new
> post and associate it with Joe's blog, find specific comments, change
> properties of posts, etc). That is the sense of model I was implying:
> very concrete and dealt with at a programming level.
Concepts? Those sound like data structures or data objects (unless
your app understands far more about those things than is necessary
for supporting blogging).
I can understand how one might want some help manipulating a large set
of related data structures, especially if some represent the same real
world object but in different contexts (such as on-disk vs in memory vs
html/jsp).
Is this really a hard problem for this application or is this just a
toy application for working out some details for a much larger
system? In other words, why are you using the heavy equipment?
(I like bulldozers more than the next guy, but ....)
-andy
Those were just simple examples to frame the discussion at a very
concrete level. The models I used to work with were a combination of
process/workflow, service and a data transformation models providing
the ability to visually compose services by specifying the control and
data flows connecting them. These models had to support visual tools on
top of them and different types of persistence. A framework like EMF
(even if build in house) is definetely a necessity.
-- yuri
······@earthlink.net wrote:
> Lemon wrote:
> > If I am building a bloggling app, my app will need to manipulate
> > domain concepts like blogs, posts, comments, etc (e.g. create a new
> > post and associate it with Joe's blog, find specific comments, change
> > properties of posts, etc). That is the sense of model I was implying:
> > very concrete and dealt with at a programming level.
>
> Concepts? Those sound like data structures or data objects (unless
> your app understands far more about those things than is necessary
> for supporting blogging).
>
> I can understand how one might want some help manipulating a large set
> of related data structures, especially if some represent the same real
> world object but in different contexts (such as on-disk vs in memory vs
> html/jsp).
>
> Is this really a hard problem for this application or is this just a
> toy application for working out some details for a much larger
> system? In other words, why are you using the heavy equipment?
> (I like bulldozers more than the next guy, but ....)
>
> -andy
From: Ken Tilton
Subject: Re: Relationships between objects in CLOS
Date:
Message-ID: <sF1tg.286$x52.39@fe12.lga>
Lemon wrote:
> Ken Tilton wrote:
>
>>Point of information: "model" to me is a rather general and abstract
>>word which seems to be used below as if it has a very specific meaning.
>>Yes? No? Are we talking about UML or something? is the big win the bit
>>about "technology neutral"?
>>
>
> It is indeed an overused term, but I was not using it in the UMLstract
> sense. If I am building a bloggling app, my app will need to manipulate
> domain concepts like blogs, posts, comments, etc (e.g. create a new
> post and associate it with Joe's blog, find specific comments, change
> properties of posts, etc). That is the sense of model I was implying:
> very concrete and dealt with at a programming level.
OK, but then why do I need EMF if, as Graham says, I can build my
language up to the domain? No, Java does not do that other than with
(ick) singly-inheritant class descriptions (not that that is not a start).
>
>
>
>>I build models out of CLOS. I persist with AllegroStore or Rucksack or
>>cl-xml or print/read. I use Cells to connect everything. I do not use a
>>second language from which Lisp is generated, and indeed this "model
>>building" is Just Programming.
>>
>>As with AOP, EMF just sounds like another measure of how hard it is to
>>develop big, complex systems with a fundamentally primitive and broken
>>language like Java.
>>
>
> I agree to some extent. I agree that Java as a language leaves a lot to
> be desired and makes the job of a programmer harder. That may increase
> the appeal of using something like EMF in the Java world, but even so,
> there are features in EMF that go beyound event to what CL and CLOS
> support out of the box. One example is the need to implement something
> like Cells in CL (if I understood its general idea correctly).
OK, but now we are not talking about limits to the abstraction one can
achieve. I mean, I /did/ manage to add constraints directly to Lisp,
such that rules are written simply in Lisp with all its expressive
power. But to me this constraints thing is not about abstractive power,
it is just something no one thought to build into a language. hell, I
have reached the point where it seems to me they simply missed the boat
on computer programming when they built the first computer and did not
implement dependency trackingin hardware.
>
> I am a first hand witness of how one has to integrate a varied of
> different libraries and frameworks in order to get an implementation
> done in Java. I imagine that is still true in CL, but maybe to a small
> degree because the language provides the flexibility needed to remove
> all the unneeded crap and hide what the programmer shouldnt be dealing
> with.
>
>
>>Lemon wrote:
>>
>>>Following are some features I use from EMF. I dont care much about
>>>Java, EMF or MOF per se and I am by no means preaching them here, but I
>>>do care about the high level and concrete benefits that a framework
>>>like EMF brings to building real applications:
>>
>>Well of course a good Lisp programmer works at a terrifically high level
>>thanks to macros and reflection and CLOS etc etc etc. I think the
>>culture clash is the very idea of looking for EMF (as in a distinct tool
>>to be learned) in Lisp when Lisp /is/ EMF.
>>
>
> I can see that to some extent as I mentioned above. CL didnt preclude
> the need to create Cells, for instance. On the other hand, I can also
> see that a lot of the value and design decisions in EMF where driven by
> Java's limitations. EMF takes a lot of the pain out of the programmer
> when writing consistent models in Java, but surely adds a bunch of
> other pains to the mix.
>
> One of my goals re: CL is understand the pains it removes and the pains
> it adds; gauge what have I been missing all these years building
> applications in Java. And representing domain models in CL is one
> focus.
>
>
>>>- EMF provides an infrastructure to use model in a Java application.
>>>- Based on OMG's MOF: abstract language and framework for specifying,
>>>constructing, and managing technology neutral metamodels
>>
>>Neutrality? I want to bury other languages, not have a gateway to them.
>>
>
> I consider the above MOF's goal at a larger scope than the programming
> level we have been talking about here. The world is not just CL or Java
> and the fact that the models can be described at a meta-model level
> means that I can share models between CL and Java: both instances of
> the models but also the models themselves. MOF is a meta-model
> (circular) that allows one to describe domain models. It is a small
> subset of UML. XMI is just an XML representation of anything produced
> by MOF instances being them domain models or their domain model
> instances. However, I prefer not to emphasize that since it is a can or
> worms...
>
>
>>>- Various Eclipse projects are relying on EMF to create models
>>>- Notification framework: there is a well defined API for being
>>>notified about state changes in EMF object attributes/references (i.e.
>>>slots).
>>
>>This is where Cells would come in.
>>
>
> In my first read of Cells, I got the impressions that it allows one to
> create calculated slots only, but it seems that it can do more than
> that.
When you add propagation from changed dependency to "calculated slot",
the imperative paradigm reverses course and flows in the other
direction: all application behavior arises from serial assignments of
new values to places one value at a time.
> I'll take a deeper look. Can I consider the docs in the Cell
> project site the main source?
You might look for cells-manifesto.txt in the source distro, or some
nice discussions in the PyCells archive. The doc you can find on my web
site and in things like 01-cell-basics.lisp are syntactically out of
date but make all the points.
> Or are there other documents I should be
> aware of?
>
>
>>>- Serialization framework: create your models in EMF and you
>>>automatically serialize them to XMI or a custom schema. Proxy
>>>resolution and demand loading framework. At least two projects I know
>>>of are working on a framework that can automatically persist your
>>>models to a relational database.
>>
>>Here again I would hold out for persistent CLOS and avoid the ugliness
>>and hassle of changing my representation merely to persist.
>>
>>
>>>- Reflexive API and Dynamic model definition: create and introspect
>>>models dynamically
>>
>>Beyond the Java reflection package?
>>
>
> Yes. I am able to reflect at the domain model level. However, I have to
> use a generic API to do that (I can hear already the "arghhh" in the
> crowd ... :-)).
>
>
>>>- Bidirectional reference handshaking: both end of the relationship are
>>>always kept in sync
>>>- Simple models constraints on objects and relationships
>>>- Tracking modifications
>>
>>Cells again.
>>
>
> Ok, I'll definetely have to read on Cells.
>
>
>>>- Validation framework
>>
>>Would that be the Lisp compiler?
>>
>
> :-) Can the List compiler guarantee or at least validate that blog
> posts cannot have more than 100 comments? Or that an employee cannot be
> its own employer?
And of course one could enforce that in code, no need to do it in EMF. I
will guess that there is a declarative quality to expressing in EMF that
makes you prefer it to coding up the same rule directly. yes,
declarative rocks, and is possibly the greatest charm of Cells
programming: just state the rule and sit back and let the engine do the
rest.
kenny
--
Cells: http://common-lisp.net/project/cells/
"I'll say I'm losing my grip, and it feels terrific."
-- Smiling husband to scowling wife, New Yorker cartoon
On 2006-07-11 02:03:32 -0500, Ken Tilton <·········@gmail.com> said:
> I build models out of CLOS.
Ditto, and -- to the OP -- I would opine that 'out of the box' is not so
important a consideration with Lisp as it is with other languages.
I find building DSLs a more effective and efficient approach than
heaping on the frameworks.
(Note that I deliberately avoided the 'model' issue, lest I end up
sounding like Fabian Pascal. I'll save that for troll-flogging ;-)
> I persist with AllegroStore or Rucksack or cl-xml or print/read.
I built a layer on top of Sven Van Caekenberghe's cl-prevalence.
The 'prevalence' assumptions work for us, even with over twenty
web-apps running on our server.
> I use Cells to connect everything. I do not use a second language from
> which Lisp is generated, and indeed this "model building" is Just
> Programming.
Sorry Kenny. Haven't tried Cells yet. My background predisposes
me to favour the relational model, and I haven't completely worked
out how many 'object-oriented' concessions I'm willing to make or
how Cells would factor in to the equation. For now, I'm defining entity
classes, methods, and various constraints by writing things the following:
(define-entity-class employee
((username (string :min-length 2 :max-length 255) :default ""
:unique t)
(password (string :min-length 2 :max-length 255) :default "")
(name (string :min-length 1 :max-length 255) :default "")
(address (string :min-length 0 :max-length 255) :default "")
(birthdate utc-date :default (utc-date "1970-01-01"))
(payrate (decimal :min #D24000.00) :default #D24000.00)
(jobtitle-oid (oid :references jobtitles) :default base-oid)
(contacts (contact-list) :default nil))
((age (utc-date/years- (today) birthdate)))
(:unique (name address))
(:constraint (or (< age 30) (< payrate #D30000.00)))
(:system *persistence-system*)
(:print-object
(lambda (object stream)
(format stream "~A (~A)"
(name object) (username object))))))
-Mike
--
Michael J. Forster <····@sharedlogic.ca>
Hi, Kenny
BTW I just trying to learn CELLS. I couldn't find how to update value
of input cell if slot didn't have accessor (it has only reader). Or it
can be updated only through accessor ?
I don't want to allow any function from this package to change value of
this slot, it is considered internal for class boiler. Or I am trying
to do something hostile to CLOS/CELLS philosophy ?
Like slot 'temp' in example below:
(defmodel boiler ()
((temp :initform (c-in 20.0) :reader boiler-temp)
(is-hot-p :initform (c? (when (>= (boiler-temp self) 50.0) t))
:reader is-hot-p)
(is-boiling-p :initform (c? (when (>= (boiler-temp self) 100.0) t))
:reader is-boiling-p)))
(defmethod warm-it ((self boiler))
(with-slots (temp) self
(incf temp 5.0))
(format t "Temp: ~D Hot? ~D Boiling? ~D~%"
(boiler-temp self) (is-hot-p self) (is-boiling-p self)))
Thanks in advance
Lisper
From: Ken
Subject: Re: Relationships between objects in CLOS
Date:
Message-ID: <ZKPsg.2$Su.0@fe10.lga>
Lisper wrote:
> Hi, Kenny
>
> BTW I just trying to learn CELLS. I couldn't find how to update value
> of input cell if slot didn't have accessor (it has only reader). Or it
> can be updated only through accessor ?
Currently Cells works by going thru accessor names declared in the slot
specification. (setf slot-value) is a back door to Cells; you should be
able to do it, but not get any Cell value propagation from such writes.
A MOP-based version I used to have would have worked the way you are
thinking -- that implemented Cells at slot-value-using-class.
With Cells the way it works now you would have to do:
(setf (cells::md-slot-value boiler 'temp) 98.6)
I have never tried that, but that is what the macroexpansion of defmodel
generates for slot writers.
> I don't want to allow any function from this package to change value of
> this slot, it is considered internal for class boiler. Or I am trying
> to do something hostile to CLOS/CELLS philosophy ?
I think it is a little hostile to Lisp philosophy, where we do not worry
so much about trying to get code quality by limiting access. But mostly
it just never occurred to me to export md-slot-value.
kt
2Pascal Bourguignon
>slot-value is an accessor.
If one of functions (not considered as internal for the class) want to
use SLOT-VALUE to set new value, I will know about it.
IMHO it is useful delimitation - if slot does not have accessor, you
are not allowed to change it directly (I want to hide internal
details), and only "internal functions" allowed to work with slots
directly. Why It is wrong ? Or should I create separate package for
each class to hide accessors from outside ?
2Ken
Thanks for explanation. This is exactly what I want to do.
Final version of that boiler:
(defmodel boiler ()
((temp :initform (c-in 20.0) :reader boiler-temp)
(is-hot-p :initform (c? (when (>= (boiler-temp self) 50.0) t))
:reader is-hot-p)
(is-boiling-p :initform (c? (when (>= (boiler-temp self) 100.0) t))
:reader is-boiling-p)))
(defmethod start-boiling ((self boiler))
(loop until (is-boiling-p self) do
(incf (cells::md-slot-value self 'temp) 5.0)
(sleep 0.6)
(format t "Temp: ~D Hot? ~D Boiling? ~D~%"
(boiler-temp self) (is-hot-p self) (is-boiling-p
self))))
>I think it is a little hostile to Lisp philosophy, where we do not worry
>so much about trying to get code quality by limiting access. But mostly
>it just never occurred to me to export md-slot-value
IMHO it is very important question. How to control references to slots
between classes of one package (If want many classes per package) ? I
try to work out some style rules for my self, but not sure that it is
common practice. I already have 500K lisp project written with use of
these style rules, but going to make it more maintainable.
Unfortunately I have no books or another materials about building large
Common Lisp applications. I like Peter Seibel's PCL and Paul Graham's
very much and other books, but can't find anything about good design of
realworld interactive multithreaded applications.
Best regards
Lisper
From: Ken
Subject: Re: Relationships between objects in CLOS
Date:
Message-ID: <ULSsg.20$pX2.3@fe08.lga>
Lisper wrote:
> Thanks for explanation. This is exactly what I want to do.
>
> Final version of that boiler:
>
> (defmodel boiler ()
> ((temp :initform (c-in 20.0) :reader boiler-temp)
> (is-hot-p :initform (c? (when (>= (boiler-temp self) 50.0) t))
> :reader is-hot-p)
> (is-boiling-p :initform (c? (when (>= (boiler-temp self) 100.0) t))
Why not just?: (c? (>= (boiler-temp self) 100.0))
And where the symbol 'self' is tour object, you can:
(c? (>= (^boiler-temp) 100.0))
No big deal.
> :reader is-boiling-p)))
>
> (defmethod start-boiling ((self boiler))
> (loop until (is-boiling-p self) do
> (incf (cells::md-slot-value self 'temp) 5.0)
> (sleep 0.6)
> (format t "Temp: ~D Hot? ~D Boiling? ~D~%"
> (boiler-temp self) (is-hot-p self) (is-boiling-p
> self))))
>
>
>>I think it is a little hostile to Lisp philosophy, where we do not worry
>>so much about trying to get code quality by limiting access. But mostly
>>it just never occurred to me to export md-slot-value
>
>
> IMHO it is very important question. How to control references to slots
> between classes of one package (If want many classes per package) ?
Yes, absolutely, most of us programmers have self-imposed constraints we
use to make it easier to develop software. Always do this, never do
that. And a lot of things are just self-documenting. Oh, no writer?
Don't touch.
kt
Ken wrote:
> Why not just?: (c? (>= (boiler-temp self) 100.0))
> And where the symbol 'self' is tour object, you can:
>
> (c? (>= (^boiler-temp) 100.0))
>
> No big deal.
:-)) Yes, it is funny to check boolean value twice, it never appears in
my production code. I was in hurry writing that example, it must be
something subconscious from previous life (Pascal or BASIC ???).
Lisper wrote:
> > IMHO it is very important question. How to control references to slots
> > between classes of one package (If want many classes per package) ?
>
Ken wrote:
> Yes, absolutely, most of us programmers have self-imposed constraints we
> use to make it easier to develop software. Always do this, never do
> that. And a lot of things are just self-documenting. Oh, no writer?
> Don't touch.
Unfortunately It doesn't work for comparatively large projects with
several programmers. If one programmer change something in one piece of
code, another programmer's piece will not work. There must be some
discipline incorporated in language constructions (possibly different
for each project), otherwise how to remember all these rules and how to
ensure that everybody keep style rules ?
And how to detect and validate bad cases (accessing to internal
details) in code ?
Best regards
Lisper.
On 11 Jul 2006 12:49:12 -0700, "Lisper" <···········@mail.ru> wrote:
>
>Ken wrote:
>> Yes, absolutely, most of us programmers have self-imposed constraints we
>> use to make it easier to develop software. Always do this, never do
>> that. And a lot of things are just self-documenting. Oh, no writer?
>> Don't touch.
>
>Unfortunately It doesn't work for comparatively large projects with
>several programmers. If one programmer change something in one piece of
>code, another programmer's piece will not work. There must be some
>discipline incorporated in language constructions (possibly different
>for each project), otherwise how to remember all these rules and how to
>ensure that everybody keep style rules ?
I really don't think Common Lisp is worse than other languages
here. Just as an example, it only takes one person ignoring
standard practice for 'const' in a C++ codebase to screw it up for
everyone else. No matter how many rules are enforced by the base
language, there will always be project-specific conventions
that have to be followed -- more so as a project gets large --
and responsible programmers have to pay attention. So even if
you're programming in Java, C++, or Ada, a large, organized team
is going to have a coding guidelines document of some kind.
Also, the scope of the problem depends on the size of the team,
how well everybody communicates, experience level of team members,
etc. Again, this is not a Lisp problem.
Whereas, the fact that you *can* do some things in CLOS easier
than might be done in other languages is an advantage that
knowledgeable folks can take advantage of.
But at the end of the day, documentation and communication
is key.
>And how to detect and validate bad cases (accessing to internal
>details) in code ?
Code reviews?
--
Jack Unrue
"Lisper" <···········@mail.ru> writes:
[...]
You could have both a :reader (for everybody) and an :accessor (for
insiders), using a non-exported symbol naming the latter:
(defclass foo ()
((slot :reader slot-of :accessor %slot-of ...)))
I don't know whether Cells supports this.
--
Marcus Breiing
"Lisper" <···········@mail.ru> writes:
> Hi, Kenny
>
> BTW I just trying to learn CELLS. I couldn't find how to update value
> of input cell if slot didn't have accessor (it has only reader). Or it
> can be updated only through accessor ?
> I don't want to allow any function from this package to change value of
> this slot, it is considered internal for class boiler. Or I am trying
> to do something hostile to CLOS/CELLS philosophy ?
slot-value is an accessor.
> Like slot 'temp' in example below:
>
> (defmodel boiler ()
> ((temp :initform (c-in 20.0) :reader boiler-temp)
> (is-hot-p :initform (c? (when (>= (boiler-temp self) 50.0) t))
> :reader is-hot-p)
> (is-boiling-p :initform (c? (when (>= (boiler-temp self) 100.0) t))
> :reader is-boiling-p)))
>
> (defmethod warm-it ((self boiler))
(incf (slot-value object 'temp) 5.0)
> (with-slots (temp) self
> (incf temp 5.0))
> (format t "Temp: ~D Hot? ~D Boiling? ~D~%"
> (boiler-temp self) (is-hot-p self) (is-boiling-p self)))
>
>
> Thanks in advance
> Lisper
>
--
__Pascal Bourguignon__ http://www.informatimago.com/
THIS IS A 100% MATTER PRODUCT: In the unlikely event that this
merchandise should contact antimatter in any form, a catastrophic
explosion will result.
From: Patrick May
Subject: Re: Relationships between objects in CLOS
Date:
Message-ID: <m2k66j7u6s.fsf@Dagney.local>
Ken Tilton <·········@gmail.com> writes:
> But at least now I understand why Bradshaw loses it so badly when he
> talks about Java. It is a funny kind of way for programming to
> die... death by obsucation or something.
Best typo of the week. "Obsucation" (obsuckation?) deserves to
be a word.
Regards,
Patrick