Hi Dennis
2010/12/6 :
> Could this easily be used (and would it make sense to use them) in this
> situation? I think the best solution is for get/set to be keywords, but
> only in the context of a property definition. Will this accomplish the
> task?
I'm sure it can be done, but I'm not sure h
>> Interesting. So you are saying that once a word is a keyword in PHP, it
>> cannot be used as a name, anywhere? So for example, you are saying I
>> cannot create a variable called $function? If that is the case, that is
>> extremely odd. I would expect that get/set could be keywords when used
On Sunday, December 05, 2010 11:07:49 am presid...@basnetworks.net wrote:
> > The "original purpose" being, specifically, "smarter class members",
> > correct? (The internal syntax to define them we can bikeshed later;
> > determining the external syntax and semantics has to come first.)
>
> Wel
Hi!
i actually implemented this in userland, but its rather ugly:
It is ugly because you try to have one class with two semantics. It is a
mistake. If you remove this ambiguity it actually would be quite small.
--
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(40
On Sun, 05 Dec 2010 10:29:29 -0800
Stas Malyshev wrote:
> Hi!
>
> > I propose to allow to work with DateTime objects that are marked as
> > immutable optionally. This means that all methods add, sub, modify,
>
> I think it's a bad idea, which would instantly break all the code that
> assumes d
On Sun Dec 5 12:44 PM, Benjamin Eberlei wrote:
>
> 1. Just create a DateTimeValue object that is immutable, not
> optimizing PHP to handle it with efficient garbage collection.
> 2. One step further, add a "static class DateTimeValue" like syntax
> that creates an immutable class.
>
> Any ideas
On Sun, Dec 5, 2010 at 7:02 PM, troels knak-nielsen wrote:
> On Sun, Dec 5, 2010 at 6:44 PM, Benjamin Eberlei wrote:
>> So currently preferred over my patch are two solutions:
>>
>> 1. Just create a DateTimeValue object that is immutable, not optimizing PHP
>> to handle it with efficient garbage
Hi!
I propose to allow to work with DateTime objects that are marked as
immutable optionally. This means that all methods add, sub, modify,
I think it's a bad idea, which would instantly break all the code that
assumes different semantics. Yes, I noticed the word optional, however,
the code
On Sun, Dec 5, 2010 at 6:44 PM, Benjamin Eberlei wrote:
> So currently preferred over my patch are two solutions:
>
> 1. Just create a DateTimeValue object that is immutable, not optimizing PHP
> to handle it with efficient garbage collection.
> 2. One step further, add a "static class DateTimeVa
On Sun, 5 Dec 2010 08:18:46 -0800
Herman Radtke wrote:
> > You don't need to know if the instance is immutable or not, since the
> > current DateTime instances also return themselves for method chaining. So
> > any code that looks like:
> >
> > $d = $d->modify("+1 hour");
> >
> > would work no
Hi Dennis
2010/12/5 :
> Interesting. So you are saying that once a word is a keyword in PHP, it
> cannot be used as a name, anywhere? So for example, you are saying I
> cannot create a variable called $function? If that is the case, that is
> extremely odd. I would expect that get/set could b
Hi Chad,
> Having thought a bit about this, there are a couple of initial
> problems I see, and, more importantly, I'm not convinced that the
> stated problem (encapsulation) requires the addition of a new language
> construct (i.e. a "property" as distinct from a "class member"). In
> fact, I th
>>> How does one get a reference to a property, if a property is just a
>> collection
>>> of methods with fancy behavior? That makes properties a first class
>> entity,
>>> which is an entirely different bit of brain bending.
>>
>> Its the same concept as having a reference to a function, where yo
>> Its a defacto standard. Of course there is nothing stopping PHP
from
>> implementing properties that way, but by going against the
standard set
>> by
>> the rest of the industry, it is very confusing for programmers
coming
>> from
>> other lang
> In a multi-user system, any of these values could be different from
> one moment to the next.
>
> class Account{
> public property $AvailableBalance{
> get{
>return $this->CreditLimit - ($this->AccountBalance - $this->OnOrder);
> }
> }
> }
>
> This hides the mechanics away and tells any
> You don't need to know if the instance is immutable or not, since the current
> DateTime instances also return themselves for method chaining. So any code
> that looks like:
>
> $d = $d->modify("+1 hour");
>
> would work no matter mutable/immutable. This is still a bit strange though.
> But st
I wondered before why this only triggers a warning. A fatal error sounds good
at that point in my opinion.
It is comparable to interfaces/Abstract classes being implemented wrong and
this also leads to a fatal error. Additionally there is no way this "just"
happens to your code. You have to mak
Hi:
While preparing some explanations on how to use traits, I stumbled over an
inconsistency in the current implementation.
Currently collisions, if they are explicit in the code, lead to a warning and
are resolved by explicit exclusion of the two methods that collide[1].
However, there are oth
Anyone, please?
2010/11/29 Patrick ALLAERT
> Can someone please approve eyal's account request with the following
> karma?:
> php/php-src/*/tests
>
> Thanks,
> Patrick
>
> 2010/11/22 Patrick ALLAERT :
> > Eyal provided already a fair number of contributions/remarks on the
> php-qa ML.
> >
> > Re
Hey Larry,
You don't need to know if the instance is immutable or not, since the current
DateTime instances also return themselves for method chaining. So any code that
looks like:
$d = $d->modify("+1 hour");
would work no matter mutable/immutable. This is still a bit strange though. But
stil
I'd love to have a Value Object version of DateTime, as its current behavior
is quite annoying.
However, making it a toggle on the existing class does not make sense to me.
A function or method that gets called with a DateTime object then doesn't know
if it is safe to modify or not, and if the
21 matches
Mail list logo
