On Thursday 28 September 2006 17:57, Matt Diephouse wrote:
> Why not handle this like we handle subroutines? That is, why don't we
> have a find_method opcode that returns a bound method? That simplifies
> parsing for IMCC and makes PIR a little simpler.
> obj.'abc'() # call 'abc' method of ob
Allison Randal <[EMAIL PROTECTED]> wrote:
> .local string abc
>
> obj.'abc'() # call 'abc' method of obj
> obj.abc()# always the same as above
> obj.{abc}() # call method indicated by abc symbol
> obj.{S0}() # call metho
Am Donnerstag, 28. September 2006 22:53 schrieb Allison Randal:
> Leopold Toetsch wrote:
> > Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud:
> >> obj.'abc'() # call 'abc' method of obj
> >> obj.abc()# always the same as above
> >> obj.{ab
Leopold Toetsch wrote:
Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud:
obj.'abc'() # call 'abc' method of obj
obj.abc()# always the same as above
obj.{abc}() # call method indicated by abc symbol
This makes a lot of sen
Patrick R. Michaud wrote:
On Thu, Sep 28, 2006 at 11:59:52AM -0700, chromatic wrote:
On Thursday 28 September 2006 11:25, Allison Randal wrote:
obj.{bar}() # a string method name
obj.{$S1}()
I'm not sure what's meant by "a string method name" above, but
I'd look at it a
Am Donnerstag, 28. September 2006 21:42 schrieb Patrick R. Michaud:
I'm just quoting the relevant pieces here and add some comments below:
> obj.'abc'() # call 'abc' method of obj
> obj.abc() # always the same as above
> obj.{abc}() # call meth
On Thursday 28 September 2006 12:42, Patrick R. Michaud wrote:
> > To push a little more the other direction, is it possible for the
> > compiler to detect symbol and method name conflicts?
> > It's only the collision that makes a case ambiguous, right?
> I don't think that the compiler always
On Thu, Sep 28, 2006 at 11:59:52AM -0700, chromatic wrote:
> On Thursday 28 September 2006 11:25, Allison Randal wrote:
> > obj.{bar}() # a string method name
> > obj.{$S1}()
I'm not sure what's meant by "a string method name" above, but
I'd look at it as:
.local string
On Thursday 28 September 2006 11:25, Allison Randal wrote:
> Exactly, change the most common case (of a method call by bare name) to
> be the unmarked case, and use some additional marking on the less common
> case of calling a method by a string name or method object. I wouldn't
> use '$' to mark
Jonathan Scott Duff wrote:
To be on the safe side, method (and function) names *should* be quoted. I
don't think that this is inconsistent.
Is there a reason that you would want to conflate method names and
variables used as a method name? If not, why not change the syntax
slightly so that me
On Wed, Sep 27, 2006 at 11:38:10AM +0200, Leopold Toetsch wrote:
> Am Mittwoch, 27. September 2006 09:12 schrieb Allison Randal:
>
> > The basic problem is inconsistency. For hand-written code the current
> > PIR method call syntactic sugar is mildly annoying. (It'd be nice to
> > safely get rid o
Am Mittwoch, 27. September 2006 09:12 schrieb Allison Randal:
> The basic problem is inconsistency. For hand-written code the current
> PIR method call syntactic sugar is mildly annoying. (It'd be nice to
> safely get rid of the quotes around the method name.)
Not easily:
obj.'foo'() # a met
Leopold Toetsch wrote:
There seems to be the impression that generating PIR calls from a compiler is
hard because it may look like:
$S0 = obj.'_meth'(arg1, arg2)
but this also works:
.pcc_begin
.arg "hello"
.arg "\n"
.invocant obj
.meth_call "_meth"
.result $S0
.
There seems to be the impression that generating PIR calls from a compiler is
hard because it may look like:
$S0 = obj.'_meth'(arg1, arg2)
but this also works:
.pcc_begin
.arg "hello"
.arg "\n"
.invocant obj
.meth_call "_meth"
.result $S0
.pcc_end
There's a simila
14 matches
Mail list logo
