turning PHP's internals into a sort of OOP framework.
> >>
> >> Regards,
> >>
> >> Richard.
> >>
> >
> > PHP does not support multiple inheritance. So no, this doesn't solve
> > really the issue.
> >
>
bstantial), please raise
> it soon.
>
> --
> Gustavo Lopes
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
*Brandon Wamboldt*
Software Engineer
Resume/CV <http://brandonwamboldt.com/cv/>
xceptions for everything but advisory errors (E_STRICT, E_NOTICE,
> >> > > E_DEPRECATED). Why? Because the current error system encourages
> >> ignoring
> >> > or
> >> > > not checking what the error was, and it makes defensive programming
> >> quite
&
ons
> everywhere is the big one for me. Namespaces as meta-objects and
> namespace private functions, definitely.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
*Brandon Wamboldt*
Programmer / Web De
be dropped (and it doesn't need to be a
> soft failure).
>
> Marco Pivetta
>
> http://twitter.com/Ocramius
>
> http://marco-pivetta.com
>
>
>
> On 17 July 2012 16:14, Brandon Wamboldt wrote:
>
>> Aren't certain modules included in the PHP core d
;t have
> > > to have their binaries bloated by legacy code. It would also mean that
> > > the legacy implementation can be developed away from the new core, and
> > > not have any (negative) influence on it.
> > >
> > > --
> > > PHP Internals - PHP R
gt; to have their binaries bloated by legacy code. It would also mean that
> the legacy implementation can be developed away from the new core, and
> not have any (negative) influence on it.
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: ht
nguage and not to mess with
> existing code. BUT: I don't know if that's doable internally. And it's
> probably a lot of work...
>
> Regards
> Thomas
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www
;); }
> }
> }
>
> Maybe you saw that the "Property get/set syntax" RFC has an intended syntax
> for read-only and write-only attributes. From my point of view, there is a
> deep and clean separation between a getter/setter syntax and an extended
> visibility synt
https://wiki.php.net/rfc/object_cast_to_types
What's the status of this RFC? I see it has a patch associated with it, and
was wondering if it would be something we'd see in 5.5 or 5.6. Does it need
to go through any sort of voting process? I'm sorry if this is the wrong
question for this mailing l
n is to reverse-engineer the Bison
> source.
> >
> >
> >
> > --
> > PHP Internals - PHP Runtime Development Mailing List
> > To unsubscribe, visit: http://www.php.net/unsub.php
> >
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
*Brandon Wamboldt*
Programmer / Web Developer
StackOverflow Careers
Profile<http://careers.stackoverflow.com/brandonwamboldt>- GitHub
Profile <https://github.com/brandonwamboldt> -
LinkedIn<https://github.com/brandonwamboldt> -
My Blog <http://brandonwamboldt.ca/>
master-only, of course. It is simpler and cleaner than
> the GUID approach and I think enough browsers can handle data URIs these
> days.
>
> -Rasmus
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/uns
rCRM: http://www.sugarcrm.com/
> (408)454-6900 ext. 227
>
>
>
--
*Brandon Wamboldt*
Programmer / Web Developer
StackOverflow Careers
Profile<http://careers.stackoverflow.com/brandonwamboldt>- GitHub
Profile <https://github.com/brandonwamboldt> -
LinkedIn<https://github.com/brandonwamboldt> -
My Blog <http://brandonwamboldt.ca/>
tps://github.com/php/php-src/pull/131
> >
> > This is the first PHP extension function, and PHP test I've written.
> >
> > --
> > Andrew Faulds (AJF)
> > http://ajf.me/
>
>
>
> --
> Andrew Faulds (AJF)
> http://ajf.me/
>
> --
> PHP Interna
14 matches
Mail list logo
