DSL vs. OOP Syntax
AdamG
I've been watching Elixir from afar for some time while using
SQLAlchemy. When using SQLAlchemy I've been using the mapping
functions inside of SQLAlchemy directly, and like many I've found that
to be somewhat repetitive and less than intuitive. I had Elixir
recommended to me by a few people, but the syntax has turned me off to
it. I'm aware that the DSL nature of it will allow you to create your
own statements, and I do realize this is a powerful feature, but it's
not what I was looking for in an ORM wrapper.
I was looking for was a syntax that allowed me to write natural Python
classes - not unlike what Django's syntax is now, or what TurboEntity
used to have. A rails-style DSL has it's advantages, but I doubt I'm
alone in feeling that, if nothing else it /looks/ awkward. Simply put,
when I want to say that a object will have an integer field, I'd
expect to write:
class MyObj(ParentClass):
number = Integer
This is close to both the SQLAlchemy and Python ways of doing
things. On the other hand, I just find that:
class MyObj(ParentClass):
has_field('number', Integer)
doesn't convey what I was trying to code: I wanted an Object with a
.number attribute that is an Integer. Putting it into a string means
that the backend code has to do some setattr(obj, 'number',...) magic,
and advantages of being able to define your own statements
notwithstanding, being able to write idiomatic Python code was what I
was looking for in a declarative layer.
So, mostly I'm just wondering if the devs would be amenable to a
"traditional" syntax for Elixir, and if users would be interested in
seeing it, or if the DSL syntax is OK for most programmers. I know
that Ben Bangert brought up this issue back in May and the decision
was to "steer clear of the discussion" for the time being, but now
seems like as good a time as any to bring it back up :). I'm not
averse to starting a separate project for an OOP-style declarative
layer, but I do want to touch base here to make sure that it isn't
something that's planned as an Elixir feature.
Thanks for your work!
Adam Gomaa
Gaetan de Menten
> I've been watching Elixir from afar for some time while using
> SQLAlchemy. When using SQLAlchemy I've been using the mapping
> functions inside of SQLAlchemy directly, and like many I've found that
> to be somewhat repetitive and less than intuitive. I had Elixir
> recommended to me by a few people, but the syntax has turned me off to
> it. I'm aware that the DSL nature of it will allow you to create your
> own statements, and I do realize this is a powerful feature, but it's
> not what I was looking for in an ORM wrapper.
>
> I was looking for was a syntax that allowed me to write natural Python
> classes - not unlike what Django's syntax is now, or what TurboEntity
> used to have. A rails-style DSL has it's advantages, but I doubt I'm
> alone in feeling that, if nothing else it /looks/ awkward. Simply put,
> when I want to say that a object will have an integer field, I'd
> expect to write:
>
> class MyObj(ParentClass):
> number = Integer
>
> This is close to both the SQLAlchemy
How is this close to SQLAlchemy?
> and Python ways of doing
> things. On the other hand, I just find that:
>
> class MyObj(ParentClass):
> has_field('number', Integer)
>
> doesn't convey what I was trying to code: I wanted an Object with a
> .number attribute that is an Integer. Putting it into a string means
> that the backend code has to do some setattr(obj, 'number',...) magic,
> and advantages of being able to define your own statements
> notwithstanding, being able to write idiomatic Python code was what I
> was looking for in a declarative layer.
The setattr thing will be there whether you notice it or not.
> So, mostly I'm just wondering if the devs would be amenable to a
> "traditional" syntax for Elixir, and if users would be interested in
> seeing it, or if the DSL syntax is OK for most programmers. I know
> that Ben Bangert brought up this issue back in May and the decision
> was to "steer clear of the discussion" for the time being, but now
> seems like as good a time as any to bring it back up :). I'm not
> averse to starting a separate project for an OOP-style declarative
> layer, but I do want to touch base here to make sure that it isn't
> something that's planned as an Elixir feature.
Ok, here is my take on it. For simple fields, I prefer the OO syntax
too. For relationships, I slightly prefer the DSL style.
In an hypothetical world where there wasn't anybody using the DSL
syntax, I'd personally be ok to go back to an OO style syntax. Now, we
are in the real world, so the DSL syntax is going to stay.
Now, do we want to support both syntax? It wouldn't be hard to do I
think. The problem is with the documentation and how we present
things. That might bring some confusion to have yet another syntax.
On the other hand, I'd find it really a shame if somebody (you or
anybody else) started another declarative layer just because of the
syntax, while most (95% at least) of the codebase could be common. So
honestly, I don't know what to do. I'd be okay to (at least try to)
make the code work both ways, and leave the OO way mostly undocumented
(it would only be an alternative to the "official" syntax) but
Jonathan might not agree with me on this since he likes the DSL thing
a lot (it was his idea after all).
--
Gaëtan de Menten
http://openhex.org
Jonathan LaCour
> Now, do we want to support both syntax? It wouldn't be hard to do
> I think. The problem is with the documentation and how we present
> things. That might bring some confusion to have yet another syntax.
>
> On the other hand, I'd find it really a shame if somebody (you or
> anybody else) started another declarative layer just because of the
> syntax, while most (95% at least) of the codebase could be common. So
> honestly, I don't know what to do. I'd be okay to (at least try to)
> make the code work both ways, and leave the OO way mostly undocumented
> (it would only be an alternative to the "official" syntax) but
> Jonathan might not agree with me on this since he likes the DSL thing
> a lot (it was his idea after all).
Okay, I have had lots of discussions on this over the past few months,
and its becoming more and more clear that the majority of people prefer
the more traditional approach when it comes to defining fields. So,
with that said, I think we need to listen to our users here, and start
supporting the traditional syntax, but only for defining fields. I
think the relation style needs to remain as a DSL-like approach.
That being said, I think its time that we went ahead and deprecated
`with_fields` in favor of the "OO" approach, since the syntaxes will end
up being quite similar, with the added bonus of preserving field order:
class Person(Entity):
id = Field(Integer, primary_key=True)
name = Field(String)
has_many('pets', of_kind='Pet', inverse='owner')
In the long-term, we might want to deprecate `has_field` as well, so
that we will have only one way to do things. I am hesitant to do this
right now, but I haven't been happy having two ways to do the same thing
for some time now, and I think we need to resolve this at some point.
So, the long and short of it is that I will finally break down, so I
don't have to hear about it anymore ;) So, whoever wants this, please go
ahead and work on a patch, and we'll try to get it into the 0.4 release
so that people can use it sooner rather than later. I want this to be
the last major API breakage before we release 0.4, and hopefully for a
long time to come. The patch should contain tests and documentation
updates before we'll accept it.
Gaetan, Daniel, how do you guys feel about this?
--
Jonathan LaCour
http://cleverdevil.org
elve...@gmail.com
> So, mostly I'm just wondering if the devs would be amenable to a
> "traditional" syntax for Elixir, and if users would be interested in
> seeing it, or if the DSL syntax is OK for most programmers. I know
> that Ben Bangert brought up this issue back in May and the decision
> was to "steer clear of the discussion" for the time being, but now
> seems like as good a time as any to bring it back up :). I'm not
> averse to starting a separate project for an OOP-style declarative
> layer, but I do want to touch base here to make sure that it isn't
> something that's planned as an Elixir feature.
I am new to world of databases in general and using Elixir has solved
many of my needs and made it enjoyable at the same time. But recently
I've been interested in trying to do things in less orthodox ways and
I think I hit a wall [1] with Elixir. I don't know if that wall can be
overcome easily or not, but I think I hit that wall in the first place
because I was expecting Elixir objects behave like regular objects and
thus I wanted to try some more advanced features that Python language
offers.
I think it would be great if Elixir objects behaved more like Python
objects. Hopefully this would make those objects more easily
manipulable and combined with other types of Python idioms and tools
that are the reason why I love using Python so much in the first
place.
I hope I understood the issue ... If not, pardon my ignorance ... :-)
---
[1] In case anybody is wondering, my main issue is how fields are
declared. I've been reviewing the process and all that getframe
hacking is a neat thing that I had never ever thought of or had to
deal directly before, but certainly it is not how I expected things to
work.
AdamG
On Aug 29, 10:36 am, Jonathan LaCour <jonathan-li...@cleverdevil.org>
wrote:
> Okay, I have had lots of discussions on this over the past few months,
> and its becoming more and more clear that the majority of people prefer
> the more traditional approach when it comes to defining fields. So,
> with that said, I think we need to listen to our users here, and start
> supporting the traditional syntax, but only for defining fields. I
> think the relation style needs to remain as a DSL-like approach.
>
> That being said, I think its time that we went ahead and deprecated
> `with_fields` in favor of the "OO" approach, since the syntaxes will end
> up being quite similar, with the added bonus of preserving field order:
>
> class Person(Entity):
> id = Field(Integer, primary_key=True)
> name = Field(String)
>
> has_many('pets', of_kind='Pet', inverse='owner')
>
> In the long-term, we might want to deprecate `has_field` as well, so
> that we will have only one way to do things. I am hesitant to do this
> right now, but I haven't been happy having two ways to do the same thing
> for some time now, and I think we need to resolve this at some point.
>
> So, the long and short of it is that I will finally break down, so I
> don't have to hear about it anymore ;) So, whoever wants this, please go
> ahead and work on a patch, and we'll try to get it into the 0.4 release
> so that people can use it sooner rather than later. I want this to be
> the last major API breakage before we release 0.4, and hopefully for a
> long time to come. The patch should contain tests and documentation
> updates before we'll accept it.
Sounds good! I've got a test set up with that syntax, and am trying to
add in the support by adding a function to handle the dict_ parameter
on the init function of EntityMeta - would that be the right place to
do this? I'm mostly using the source of Statement.process and one of
the earlier TurboEntity releases as references, so if there's a better
place for it to be, let me know. It's not working as of yet, but the
long weekend coming up should be a good time to get it finished &
submitted. Should the patches be submitted to Trac now, or directly to
the devs, or ...?
Thanks,
Adam Gomaa
Adam Gomaa
the following:
* A patch to elixir/entity.py (assignment_syntax.patch) that adds a
process_attrs() method to EntityMeta, and calls it in __init__().
* A patch to docs/tutorial.rst (tutorial_assignment_syntax.patch) which
updates the code samples to use class assignment rather than
with_fields.
* The test_attr_syntax.py file, which is mostly a copy of
test_movies.py, just with the class attribute syntax.
All the patches are against SVN revision 193.
All tests still run successfully with SQLAlchemy 0.4. I did have to
make an unrelated fix on elixir/ext/associable.py to get it to work
with 0.4, but that was the case before or after these patches. I don't
have access to a machine with 0.3 right now, but I will tomorrow.
Let me know how this is.
Adam
On Thu, 30 Aug 2007 08:12:47 -0700
AdamG <akg...@gmail.com> wrote:
--
Adam Gomaa
Ad...@Gomaa.us
Daniel Haus
proposal. It seems easier to use and looks more natural to me. And it
would remove lines of code (and a level of indentation) in most of my
cases.
On 29 Aug., 16:36, Jonathan LaCour <jonathan-li...@cleverdevil.org>
wrote:
> That being said, I think its time that we went ahead and deprecated
> `with_fields` in favor of the "OO" approach, since the syntaxes will end
> up being quite similar, with the added bonus of preserving field order:
>
> class Person(Entity):
> id = Field(Integer, primary_key=True)
> name = Field(String)
>
> has_many('pets', of_kind='Pet', inverse='owner')
>
> In the long-term, we might want to deprecate `has_field` as well, so
> that we will have only one way to do things. I am hesitant to do this
> right now, but I haven't been happy having two ways to do the same thing
> for some time now, and I think we need to resolve this at some point.
>
> [...]
Gaetan de Menten
> Writing the patches ended up being pretty straightforward. Included are
> the following:
>
> * A patch to elixir/entity.py (assignment_syntax.patch) that adds a
> process_attrs() method to EntityMeta, and calls it in __init__().
>
> * A patch to docs/tutorial.rst (tutorial_assignment_syntax.patch) which
> updates the code samples to use class assignment rather than
> with_fields.
>
> * The test_attr_syntax.py file, which is mostly a copy of
> test_movies.py, just with the class attribute syntax.
>
> All the patches are against SVN revision 193.
>
> All tests still run successfully with SQLAlchemy 0.4. I did have to
> make an unrelated fix on elixir/ext/associable.py to get it to work
> with 0.4, but that was the case before or after these patches. I don't
> have access to a machine with 0.3 right now, but I will tomorrow.
Care to explain what was that fix? (or maybe we already corrected that
in the mean time).
> Let me know how this is.
These patches look good to me. For consistency's sake, I'd appreciate
if you'd implement the same for relationships. This shouldn't be
difficult though. It'll only be a tiny bit more work than for fields,
as you'd have to make Relationships be initializable without knowing
their name (as was already the case for fields).