Hi!
If committed, can we put in our CS that internal classes cannot use it?
I can almost not imagine more confusing things.
I wouldn't say cannot, but maybe should not. For regular classes it
indeed doesn't make much sense, but if representing callable things for
bridges to other languages e
On Mon, Aug 4, 2008 at 20:43, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Mon, Aug 4, 2008 at 7:59 PM, Hannes Magnusson
> <[EMAIL PROTECTED]> wrote:
>> On Mon, Aug 4, 2008 at 18:45, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
>>> Hello,
>>>
>>> On Mon, Aug 4, 2008 at 4:18 PM, Dmitry Sto
Hello,
On Mon, Aug 4, 2008 at 7:59 PM, Hannes Magnusson
<[EMAIL PROTECTED]> wrote:
> On Mon, Aug 4, 2008 at 18:45, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
>> Hello,
>>
>> On Mon, Aug 4, 2008 at 4:18 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
>>> Hi Christan,
>>>
>>> Could you please look into
On Mon, Aug 4, 2008 at 18:45, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
> Hello,
>
> On Mon, Aug 4, 2008 at 4:18 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
>> Hi Christan,
>>
>> Could you please look into this patch.
>> I'm not sure if explicit declaration of Closure::__invoke() is good idea. As
Hello,
On Mon, Aug 4, 2008 at 4:18 PM, Dmitry Stogov <[EMAIL PROTECTED]> wrote:
> Hi Christan,
>
> Could you please look into this patch.
> I'm not sure if explicit declaration of Closure::__invoke() is good idea. As
> it cannot provide proper argument information.
>
> May be the patch which you p
Hi Christan,
Could you please look into this patch.
I'm not sure if explicit declaration of Closure::__invoke() is good
idea. As it cannot provide proper argument information.
May be the patch which you propose already solves this problem for
reflection. (I didn't have time to look into it).
Hello Stanislav,
Monday, August 4, 2008, 7:06:59 AM, you wrote:
> Hi!
>> 1) With the interface, the prototype is fixed.
> That definitely would not work. Interface could leave __invoke
> undefined, though then it'd be more of documentation/attribute purpose
> than enforcing having __invoke. B
Hi Etienne,
In general the patch looks fine.
The only thing I don't like is explicit declaration of Closure::__invode
method. It won't have proper arg_info.
Thanks. Dmitry.
Etienne Kneuss wrote:
Hello,
On Sat, Aug 2, 2008 at 7:36 PM, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
Hi,
this i
Hi!
1) With the interface, the prototype is fixed.
That definitely would not work. Interface could leave __invoke
undefined, though then it'd be more of documentation/attribute purpose
than enforcing having __invoke. But it can be workable.
However, I'd still like to make closures more fl
Hello Etienne,
Monday, August 4, 2008, 12:03:01 AM, you wrote:
> Hello,
> On Sat, Aug 2, 2008 at 7:36 PM, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> this is probably not the best time to raise concerns about __invoke
>> (closures) now that alpha1 is already realeased, but I believe i
Hello,
On Sat, Aug 2, 2008 at 7:36 PM, Etienne Kneuss <[EMAIL PROTECTED]> wrote:
> Hi,
>
> this is probably not the best time to raise concerns about __invoke
> (closures) now that alpha1 is already realeased, but I believe it's
> worth it.
>
> 1) I don't believe that having it thrown as another o
11 matches
Mail list logo