any more news about the directors patch?
I'm back from my travels and (theoretically) have time to look things over.
On Fri, May 9, 2008 at 12:13 AM, Robert Stone <talby@...> wrote:
> On Thu, May 08, 2008 at 10:06:10AM -0400, Josh Cherry wrote:
>> Will it still be possible to insert Perl code? Is foo.pm gone, or just
> The main thing I'm looking to eliminate from the pm is the tie()
> related functions in the base package, and the use of inheritance in
> shadow classes that currently pushes the tie methods out to the shadow
> classes. The pm will remain, and I don't think we'd ever want to remove
> it entirely. It's the best place to call XSLoader to drag in the c lib,
> and the right place to declare packages and push pragmas at the Perl
>> Is the point about constructors related to directors?
> Yes, this should mainly be a change to typemaps so that the C
> and Perl halves of shadow object construction can be unified (without a
> fairly ugly dance number you can see in the rough pass director patch I
> wrote). That should simplify ownership management and I'm hoping will
> make more advanced features like director unwrapping much easier to
>> A complaint I've had for a while is the behavior of static methods, member
>> enums, and member constants: they don't get inherited. Does this have any
>> bearing on that? (I think I know how to solve it for static methods, in
>> terms of the code to generate.)
> Honestly, what I'd like to do with constants and enum values is
> surface them to Perl using newCONSTSUB(). It makes them functions
> rather than variables so we have to construct a migration path, but I
> think it's worth doing. It will both optimize better and yield more
> meaningful errors from Perl when user code has bugs. That change would
> also happen to make them inheritable. Does that idea strike you as
> As for static methods, I remember them having an awkward feel,
> but I don't remember why and haven't looked into them recently. In my
> head, constructors are essentially static methods that happen to return
> a new instance, so I'd personally like to see consistency in their
> calling conventions. I'll do my homework and get back to this later,
> but I'd love to hear a proposal if you've got one.
>> What are the implications for operator overloading. I've been working on
>> fixing and enhancing that, but it all happens in the class definition in
> I have been keeping overloading in mind, and I think we won't
> step on each other in ugly ways in the runtime. I have had thoughts
> that the overload magic could also be bound in C to help maintain the
> purity of the Perl namespace, but I'm not concerned about that now.
> (The correctness you're working on is vastly more important.)
> This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
> Don't miss this year's exciting event. There's still time to save $100.
> Use priority code J8TL2D2.
> Swig-devel mailing list