>-----Message d'origine-----
>De : Peter Rabbitson [mailto:[email protected]]
>Envoyé : lundi, 18. mai 2009 15:28
>Hi everyone,
>
>With SQLA 2.0 coming closer to reality, there was a substantial effort
>to clear up and disambiguate the SQLA 1.x API. One of the remaining
>quirks is the -nest operator, which was introduced in version 1.18.
>The examples provided in the documentation make no sense from a
>usability point of view, as all of them are more clearly expressed
>by other means.
[examples cut]
>The development team of SQLA 2.0 would like to know if there are
>real-world -nest usages which can not be easily expressed in any
>other ways. If this is not the case, -nest will be marked as
>deprecated by a warning starting with the next SQLA version, and
>will be completely removed in 2.0.
>
>Any input/thoughts welcome!
>
Hi Peter,
As far as I understand, when NWIGER originally introduced the -nest operator,
this was the recommended way for nesting several ANDs/ORs. The advantage of
that approach was that the motto "hashrefs are ANDs, arrayrefs are ORs" was
consistent through the whole syntax tree. Also, it was quite convenient to
merge several sets of constraints with something like
my $new_constraints = {col1 => $v1, col2 => $v2, -nest =>
$original_constraints};
where $original_constraints can be either a hashref or an arrayref, you don't
care.
Now the recommended way for nesting several ANDs/ORs is
-and => {..} | [..], -or => {..} | [..]
Personnally I preferred the old way, because now the semantics of a
(hash|array)ref depends on its outside context. This can be more complex to
read, and one must be a little careful when merging several sets of
constraints. But never mind, I agree that the new way has the same expressive
power: anything that was expressed with -nest can also be done with -and/-or.
And since the -and/-or syntax has been used for many years by the DBIC
community, which is probably the biggest user base for SQLA, that's definitely
the way to go.
Deprecating -nest might have a negative impact on SQLA users outside of the
DBIC community; but it's hard to tell how many people would be affected. As far
as our Geneva team is concerned, replacing all -nest calls in our applications
is not a big problem.
Cheers,
Laurent Dami
_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/[email protected]
