> > Am I the only one thinking this, is there actually someone who is using
> > __construct as re-initialising method?
> >
> php doesn't invoke the parent's constructor from the subclass if the
> subclass also have a constructor, so in that case calling
> parent::__construct() manually is your only
Authorities don't run away.
On Thu, Sep 12, 2013 at 3:25 AM, Pascal Chevrel wrote:
> e 12/09/2013 07:40, Daniel Brown a écrit :
>
> On Thu, Sep 12, 2013 at 12:10 AM, Seva Lapsha
>> wrote:
>>
>>> PHP is a collective mind. Any dictatorship would mean a degra
PHP is a collective mind. Any dictatorship would mean a degradation for it.
If you don't like how it's managed, there is an easy path:
1. Earn authority.
2. Propose a change.
3. Implement it.
4. Maintain it.
Start with 1.
On Wed, Sep 11, 2013 at 6:44 AM, Florin Patan wrote:
> Good day intern
Hi,
As I see it, adapters not only serve declaration purpose, they also can
adapt the method and param names and even alter or tune the execution flow.
Imagine this simple case:
You have a protocol Duck with method walk() with few concrete
implementations. Later you have another instance of Duck
The feature exists in Python:
http://stackoverflow.com/questions/574730/python-how-to-ignore-an-exception-and-proceed,
in Ruby:
http://stackoverflow.com/questions/5089802/which-is-the-shortest-way-to-silently-ignore-a-ruby-exception.
Just saying.
On Wed, May 1, 2013 at 4:46 AM, Patrick ALLAERT w
p struggling for better server-side form handling and start
> moving towards fully client-side UI...
>
> (sorry if I'm going off on a tangent here - just sharing some of the
> thoughts that lead me down this path to begin with...)
>
>
> On Tue, May 7, 2013 at 9:41 AM, Seva
;
>
> On Mon, May 6, 2013 at 1:12 PM, Seva Lapsha wrote:
>
>> BTW, I didn't propose to wrap any use of a property reference into a meta
>> object, in this case a certain distinguishable string format could
>> represent it with no extra handling.
>>
&g
eference and User.
>
> As opposed to ^$user->name which contains the minimum amount of required
> information - the object and property-name, nothing else.
>
>
> On Mon, May 6, 2013 at 12:08 PM, Seva Lapsha wrote:
>
>> Hi Rasmus,
>>
>> I agree with you that stri
to both PropertyReference and User.
>
> As opposed to ^$user->name which contains the minimum amount of required
> information - the object and property-name, nothing else.
>
>
> On Mon, May 6, 2013 at 12:08 PM, Seva Lapsha wrote:
>
>> Hi Rasmus,
>>
>> I agr
Hi Rasmus,
I agree with you that strings are not the best way to refer to an element
sometimes. However, to me your Symfony2 example only demonstrates the flaw
of the component's design decision, not the limitation of the language.
Sometimes developers (not just Symfony, but other frameworks too)
On Fri, Jan 25, 2013 at 2:04 PM, Rasmus Lerdorf wrote:
> On 01/25/2013 10:55 AM, Seva Lapsha wrote:
> > Well, how about renaming the functions, create aliases for BC and throw
> > E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
> > with the distribut
Well, how about renaming the functions, create aliases for BC and throw
E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
with the distribution to migrate to the new convention?
On Fri, Jan 25, 2013 at 1:41 PM, Stas Malyshev wrote:
> Hi!
>
> > I've seen discussion on reddi
Please read my previous comment.
On Mon, May 14, 2012 at 3:31 PM, Clint Priest wrote:
> How would one use your Castable interface to cast a Class “Test” to any
> of integer, array or boolean?
>
> ** **
>
> *From:* Seva Lapsha [mailto:seva.lap...@gmail.com]
> *Sent:* Mo
Thanks.
On Mon, May 14, 2012 at 2:28 PM, Stas Malyshev wrote:
> Hi!
>
> > Not quite. The proposed is a syntactic sugar which is thought to handle
> > any transformation of a value, not necessarily or limited to type or
> > class conversion. It is of course possible to limit the usage to just
> >
etc, so that the language
> > can request the type it needs to cast to.
> >
> > > -Original Message-
> > > From: Seva Lapsha [mailto:seva.lap...@gmail.com]
> > > Sent: Wednesday, May 09, 2012 4:56 PM
> > > To: internals@lists.php.net
>
Hi,
Not quite. The proposed is a syntactic sugar which is thought to handle any
transformation of a value, not necessarily or limited to type or class
conversion. It is of course possible to limit the usage to just that, with
any user defined convention or "best practice". In fact it's pretty
dist
it is cast to,
> which is why the __toInt(), __toArray(), etc, so that the language can
> request the type it needs to cast to.
>
> > -Original Message-
> > From: Seva Lapsha [mailto:seva.lap...@gmail.com]
> > Sent: Wednesday, May 09, 2012 4:56 PM
> > To: in
t/rfc/object_cast_to_types
https://wiki.php.net/rfc/class_casting_to_scalar
Thank you in advance,
Seva Lapsha
On Wed, Apr 11, 2012 at 6:14 PM, Yasuo Ohgaki wrote:
> Hi all,
>
> I think my RFC confused people on this list due to improper descriptions
> and too much information. Sorry for the confusi
-1
May harm code portability and maintainability, allows intended or accidental
fluctuations in code consistence.
On Sun, Nov 28, 2010 at 6:10 PM, Tjerk Meesters wrote:
> -1
>
> The nuisance of updating IDE, search tools etc doesn't outweigh typing 9
> characters less imho.
> On Nov 28, 2010 11:
19 matches
Mail list logo
