hi,
from the release notes: Note that although useful, this feature has important disadvantages and will probably be obsoleted by a better alternative in the future. ... Another method that overcomes these problems will likely be implemented. The problem is that it can give compatibility problems to change old code that uses implicit lambdas to that one, since e.g. return will work differently without giving any sort of error.
given these statements why was the opportunity not taken, to remove implicit lambda again before the 7.4 release.
anybody using 7.3 should not be depending on stability, and may be expected to change code, but now that the cat is loose it will be much harder to catch.
though i still think that the feature can be removed now, before 7.4 becomes widespread.
what reasons would be against doing that?
greetings, martin.
If you read the statement carefully, you'll see that it says that the construct is useful, and that a better alternative should appear before it is obsoleted.
/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)
Previous text:
2002-12-20 17:20: Subject: implicit lambda
hi,
from the release notes: Note that although useful, this feature has important disadvantages and will probably be obsoleted by a better alternative in the future. ... Another method that overcomes these problems will likely be implemented. The problem is that it can give compatibility problems to change old code that uses implicit lambdas to that one, since e.g. return will work differently without giving any sort of error.
given these statements why was the opportunity not taken, to remove implicit lambda again before the 7.4 release.
anybody using 7.3 should not be depending on stability, and may be expected to change code, but now that the cat is loose it will be much harder to catch.
though i still think that the feature can be removed now, before 7.4 becomes widespread.
what reasons would be against doing that?
greetings, martin.
interested in doing pike programming, sTeam/caudium/pike/roxen training, sTeam/caudium/roxen and/or unix system administration anywhere in the world. -- pike programmer working in europe csl-gmbh.net open-steam.org (www.archlab|(www|db).hb2).tuwien.ac.at unix bahai.or.at iaeste.(tuwien.ac|or).at systemadministrator (stuts|black.linux-m68k).org is.(schon.org|root.at) Martin Bähr http://www.iaeste.or.at/~mbaehr/
/ Brevbäraren
On Fri, Dec 20, 2002 at 05:30:01PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
If you read the statement carefully, you'll see that it says that the construct is useful,
i read that.
and that a better alternative should appear before it is obsoleted.
but i don't read this. a should be obsoleted by b, does not imply that a may not be obsolted while b is still missing.
the problem i see is that
Another method that overcomes these problems will likely be implemented. The problem is that it can give compatibility problems to change old code that uses implicit lambdas to that one, since e.g. return will work differently without giving any sort of error.
will introduce another incompatible change (which users always hate) i'll probably try to avoid implicit lamdas for now because of it.
it's not like: PushPop() { glTranslate( (1.0-0.08)/2, 0.0, 0.0 ); draw_stuff(); };
is so much more easy to write than:
PushPop( lambda(){ glTranslate( (1.0-0.08)/2, 0.0, 0.0 ); draw_stuff(); });
greetings, martin.
If you don't want to use it then simply don't use it (I won't, since I also think this syntactic sugar isn't that much better than a lambda). It's only if you decide to use it that you can get compatibility trouble if you later want to change _your_ implementation to the new method that might get implemented. E.g. if you wrote PushPop you might have trouble replacing it later. From the Pike core perspective there won't be any compatibility problems supporting the current implicit lambdas in code that uses them while at the same time providing another better method.
/ Martin Stjernholm, Roxen IS
Previous text:
2002-12-20 17:52: Subject: Re: implicit lambda
On Fri, Dec 20, 2002 at 05:30:01PM +0100, Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
If you read the statement carefully, you'll see that it says that the construct is useful,
i read that.
and that a better alternative should appear before it is obsoleted.
but i don't read this. a should be obsoleted by b, does not imply that a may not be obsolted while b is still missing.
the problem i see is that
Another method that overcomes these problems will likely be implemented. The problem is that it can give compatibility problems to change old code that uses implicit lambdas to that one, since e.g. return will work differently without giving any sort of error.
will introduce another incompatible change (which users always hate) i'll probably try to avoid implicit lamdas for now because of it.
it's not like: PushPop() { glTranslate( (1.0-0.08)/2, 0.0, 0.0 ); draw_stuff(); };
is so much more easy to write than:
PushPop( lambda(){ glTranslate( (1.0-0.08)/2, 0.0, 0.0 ); draw_stuff(); });
greetings, martin.
interested in doing pike programming, sTeam/caudium/pike/roxen training, sTeam/caudium/roxen and/or unix system administration anywhere in the world. -- pike programmer working in europe csl-gmbh.net open-steam.org (www.archlab|(www|db).hb2).tuwien.ac.at unix bahai.or.at iaeste.(tuwien.ac|or).at systemadministrator (stuts|black.linux-m68k).org is.(schon.org|root.at) Martin Bähr http://www.iaeste.or.at/~mbaehr/
/ Brevbäraren
On Fri, Dec 20, 2002 at 08:35:03PM +0100, Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
If you don't want to use it then simply don't use it (I won't, since I also think this syntactic sugar isn't that much better than a lambda).
:-)
It's only if you decide to use it that you can get compatibility trouble if you later want to change _your_ implementation to the new method that might get implemented. E.g. if you wrote PushPop you might have trouble replacing it later.
well, but that's not a compatibility problem, it's a problem of deciding if the new implementation fits for me. if the new way doesn't then fit then i can always go back to the old (7.2) way.
From the Pike core perspective there won't be any compatibility problems supporting the current implicit lambdas in code that uses them while at the same time providing another better method.
you mean without setting the version of the code to 7.4? i thought exactly that was the problem.
greetings, martin.
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Baehr -
Martin Stjernholm, Roxen IS ＠ Pike developers forum