Hi!
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
Thanks.
- Didier Verna qvqvre@yeqr.rcvgn.se [2017-05-17 17:33:40 +0200]:
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
Ah, but the OP specified "built-in" along with "non-standard".
hth
-hk
On Wed, May 17, 2017 at 3:24 PM, Sam Steingold sds@gnu.org wrote:
- Didier Verna qvqvre@yeqr.rcvgn.se [2017-05-17 17:33:40 +0200]:
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
-- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net https://ffii.org http://camera.org http://think-israel.org http://no2bds.org Do not worry about which side your bread is buttered on: you eat BOTH sides.
You're apparently confusing two different meaning of "standard". It's not the meaning that something is defined in the ANS and therefore built into the standard ANSI CL language. Rather, it is a standard method-combination that is not the one known as STANDARD-METHOD-COMBINATION.
On Wed, May 17, 2017 at 1:50 PM, Ken Tilton ken.tilton@weather.com wrote:
Ah, but the OP specified "built-in" along with "non-standard".
hth
-hk
On Wed, May 17, 2017 at 3:24 PM, Sam Steingold sds@gnu.org wrote:
- Didier Verna qvqvre@yeqr.rcvgn.se [2017-05-17 17:33:40 +0200]:
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
-- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net https://ffii.org http://camera.org http://think-israel.org http://no2bds.org Do not worry about which side your bread is buttered on: you eat BOTH sides.
-- *Ken **Tilton *|Software Engineer *w:* (555) 555-5555 *e:* ken.tilton@weather.com http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps
As for the original question, I don't see any reason the various built-in method combination could not have been defined to support :before and :after methods. But the way they are defined is consonant with the short form of define-method-combination, which implies that the several built-in method combinations would typically be implemented using short form d-m-c. So the scope of the original question probably should be expanded to include short form d-m-c.
On Fri, May 19, 2017 at 6:20 PM, Steve Haflich shaflich@gmail.com wrote:
You're apparently confusing two different meaning of "standard". It's not the meaning that something is defined in the ANS and therefore built into the standard ANSI CL language. Rather, it is a standard method-combination that is not the one known as STANDARD-METHOD-COMBINATION.
On Wed, May 17, 2017 at 1:50 PM, Ken Tilton ken.tilton@weather.com wrote:
Ah, but the OP specified "built-in" along with "non-standard".
hth
-hk
On Wed, May 17, 2017 at 3:24 PM, Sam Steingold sds@gnu.org wrote:
- Didier Verna qvqvre@yeqr.rcvgn.se [2017-05-17 17:33:40 +0200]:
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
-- Sam Steingold (http://sds.podval.org/) on darwin Ns 10.3.1504 http://steingoldpsychology.com http://www.childpsy.net https://ffii.org http://camera.org http://think-israel.org http://no2bds.org Do not worry about which side your bread is buttered on: you eat BOTH sides.
-- *Ken **Tilton *|Software Engineer *w:* (555) 555-5555 *e:* ken.tilton@weather.com http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps http://weather.com/apps
Steve Haflich shaflich@gmail.com wrote:
As for the original question, I don't see any reason the various built-in method combination could not have been defined to support :before and :after methods. But the way they are defined is consonant with the short form of define-method-combination, which implies that the several built-in method combinations would typically be implemented using short form d-m-c. So the scope of the original question probably should be expanded to include short form d-m-c.
Good point.
Dnia 2017-05-17, śro o godzinie 15:24 -0400, Sam Steingold pisze:
- Didier Verna qvqvre@yeqr.rcvgn.se [2017-05-17 17:33:40 +0200]:
Does anyone know why the non-standard built-in method combinations do not support before and after methods?
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
But Didier is asking about BUILT-IN method combinations. Possibly it was hard to define reasonable agreed semantics for before an after methods in the case of something like AND or APPEND (technical troubles aside).
Regards
ZJ
zbyszek zbyszek@mimuw.edu.pl wrote:
Dnia 2017-05-17, śro o godzinie 15:24 -0400, Sam Steingold pisze:
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
But Didier is asking about BUILT-IN method combinations. Possibly it was hard to define reasonable agreed semantics for before an after methods in the case of something like AND or APPEND (technical troubles aside).
Right. I was merely curious. It's pretty obvious to me why you wouldn't allow CALL-NEXT-METHOD in non-standard built-in combinations, but I can't figure out why or how before and after methods could be problematic, so I was wondering...
On 18 May 2017, at 10:42, Didier Verna didier@lrde.epita.fr wrote:
zbyszek zbyszek@mimuw.edu.pl wrote:
Dnia 2017-05-17, śro o godzinie 15:24 -0400, Sam Steingold pisze:
If you are defining the method combination, you have way more freedom and flexibility than mere before and after. Basically, you can do it yourself.
But Didier is asking about BUILT-IN method combinations. Possibly it was hard to define reasonable agreed semantics for before an after methods in the case of something like AND or APPEND (technical troubles aside).
Right. I was merely curious. It's pretty obvious to me why you wouldn't allow CALL-NEXT-METHOD in non-standard built-in combinations, but I can't figure out why or how before and after methods could be problematic, so I was wondering...
I’m just guessing, but one reason I can think of is that almost all of the built-in method combinations (except for standard and progn) are applicative. before/after methods don’t have a direct impact on the return value of a generic function call, so their primary purpose is to allow for specifying side effects, which presumably doesn’t make a lot of sense for applicative combinators.
Does that make any sense?
Pascal
-- Pascal Costanza The views expressed in this email are my own, and not those of my employer.
Pascal Costanza wrote:
I’m just guessing, but one reason I can think of is that almost all of the built-in method combinations (except for standard and progn) are applicative. before/after methods don’t have a direct impact on the return value of a generic function call, so their primary purpose is to allow for specifying side effects, which presumably doesn’t make a lot of sense for applicative combinators.
Does that make any sense?
Hmmm. Nope :-) Not much to me at least. I have several cases where I would have liked to be able to perform some kinds of sanity checks before executing a combination such as AND OR etc.
I can still manage to do it in an around method, but it feels wrong.
On 18 May 2017, at 11:05, Didier Verna didier@lrde.epita.fr wrote:
Pascal Costanza wrote:
I’m just guessing, but one reason I can think of is that almost all of the built-in method combinations (except for standard and progn) are applicative. before/after methods don’t have a direct impact on the return value of a generic function call, so their primary purpose is to allow for specifying side effects, which presumably doesn’t make a lot of sense for applicative combinators.
Does that make any sense?
Hmmm. Nope :-)
Darn. :-)
-- Pascal Costanza
-
Didier Verna -
Ken Tilton -
Pascal Costanza -
Sam Steingold -
Steve Haflich -
zbyszek