n. And, possibly, provide a magic method, or interface to
generate an hash value of an object.
Regards,
Andrew
--
Andrew Yochum
Plexpod
[EMAIL PROTECTED]
718-360-0879
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tue, Mar 07, 2006 at 01:38:34AM +0200, Zeev Suraski wrote:
> A part of the decision was to supply the few lines of code necessary
> to emulate register_globals in userspace. Volunteers? :)
FWIW, I've used this successfully when tieing two systems with opposing
register_globals requirements:
implementation? This doesn't use interfaces, but that seems
trivial. I wasn't clear if you'd envisioned taking it one step further
and do the check before invocations of __call or not.
Regards,
Andrew
--
Andrew Yochum
Plexpod
[EMAIL PROTECTED]
718-360-0879
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
tedly agree with the interface implementation vs. magic
methods. My current implementation uses interfaces. It seems that
most, if not all, magic method-like behavior might be interfaces down
the road. Just curious...what is the party line on that subject?
And does such an interface deserve to be part o
On Wed, Jan 04, 2006 at 02:23:51AM +0100, Marcus Boerger wrote:
> Hello Andrew,
>
> you got everything correct and i see your point, so you may want to open a
> feature request under bugs.php.net.
>
> marcus
Thanks. Will do.
Regards,
Andrew
--
Andrew Yochum
Plexpod
[EM
rought it up for the community's benefit, as I think it is an area
that has room for some improvement. I can see it becoming an issue as
the frameworks and libraries for 5 continues to build and are
integrated. I don't want to argue either - just trying to have
productive discussion.
Reg
x27;t agree on a consistent behavior. The result might be
lots of special cases in various levels of code, not to mention the
possibility of a fatal error if any of the __call implementations try to
behave like the language does. A change in the language could eliminate
the ambiguity.
Regard
ntly with regular properties, allowing
both classes that do and do not implement property overloading to behave
the same. It seems appropriate that the method overloading behave
similarly. An everyday end-user of the language should not need to know
if he's invoking or looking to invoke an overlo
sing the same convention. Another downside to doing it yourself is
that every call to a method must first check __is_callable - this could
be handled by the language upon a method call. If I feel it would be a
good idea to implement this in the lanaguage for standardization and
simplicity.
Regards,
t
but is_callable would/could use it, or perhaps some new function.
Is this a reasonable request? Thoughts?
Regards,
Andrew
--
Andrew Yochum
Plexpod
[EMAIL PROTECTED]
718-360-0879
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
k to be much more than just a data container,
> > > then I can foresee that I will often want/need a constructor
> > > but __construct is not called.
> > >
> > > Could this be considered a bug? Any thoughts?
> > >
> > > --
> > > -- Matt Friedman
> > &g
at what code is at fault.
See:
http://bugs.php.net/bugs-generating-backtrace.php
Tracking down the actual source of your problem will be a bit more
inovled. There are a few decent gdb tutorials online that'll get you
started.
HTH,
Andrew
--
Andrew Yochum
Plexpod
[EMAIL PROTECTED]
718-360-
your extension modify the symbol
table directly, but again, this is evil.
George
George,
Can you please substantiate your statement that drop-in replacements
are evil?
I could only see them being a problem if they don't fully implement
the existing API.
Andrew
--
Andrew Yochum
Plex
13 matches
Mail list logo
