On 20 October 2012 23:09, Michael Stowe wrote:
> I see what you're trying to do but not a big fan of how it's being
> implemented in the example given.
>
> - Mike
>
> Sent from my iPhone
>
> On Oct 20, 2012, at 4:02 PM, Rasmus Lerdorf wrote:
>
> > On 10/20/2012 01:59 PM, Nikita wrote:
> >> Hello
I see what you're trying to do but not a big fan of how it's being implemented
in the example given.
- Mike
Sent from my iPhone
On Oct 20, 2012, at 4:02 PM, Rasmus Lerdorf wrote:
> On 10/20/2012 01:59 PM, Nikita wrote:
>> Hello, list. I want to propose generics. For those, who don't know wha
On 10/20/2012 01:59 PM, Nikita wrote:
> Hello, list. I want to propose generics. For those, who don't know what it
> is, here's example: say we have a Comment class, that has a method getBody.
> Also we have Collection class, that implements Traversable. Now, if I want to
> validate all insertio
Hello, list. I want to propose generics. For those, who don't know what it is,
here's example: say we have a Comment class, that has a method getBody. Also we
have Collection class, that implements Traversable. Now, if I want to validate
all insertions into collection of comments, I would need t
On 20-10-2012 19:20, Clint Priest wrote:> Hey Rasmus, please try and
keep these replies in the appropriate thread...
>
> I am in favor of eliminating the read-only/write-only keywords and
implementing no "special code" to make what was read-only/write-only
language enforced. I think the altern
On Sat, Oct 20, 2012 at 12:09 PM, Lester Caine wrote:
>
> I am in favor of eliminating the read-only/write-only keywords and
>> implementing no "special code" to make what was read-only/write-only
>> language enforced. I think the alternatives with final are just fine and
>> good enough and wil
Clint Priest wrote:
Hey Rasmus, please try and keep these replies in the appropriate thread...
And bottom post please ...
I am in favor of eliminating the read-only/write-only keywords and implementing no
"special code" to make what was read-only/write-only language enforced. I
think the al
On 10/20/12 10:45 AM, Rasmus Schultz wrote:
Just drop the idea of read-only altogether, please - it's so marginally
useful in the first place, unconventional compared to other languages, and
Read-only is perfect for value objects, where the alternative is a bunch of protected
props and getters
Hey Rasmus, please try and keep these replies in the appropriate thread...
I am in favor of eliminating the read-only/write-only keywords and implementing
no "special code" to make what was read-only/write-only language enforced. I
think the alternatives with final are just fine and good enough
I second getting rid of write-onle - the only real case I can think of, is
something like a password property on a user/account model-type, which gets
encrypted and thus can't be read, and as Amaury pointed out, that should be
a setPassword() method instead, perhaps even a separate UserPasswordServ
On Sat, Oct 20, 2012 at 4:39 PM, Clint Priest wrote:
> The problem was that the RFC had been updated past where the code was, AFAIK
> you can't branch a wiki page, can you? That's what needed branching...
> unless you mean to create a v1.1 page and a v1.2 page, which is basically
> what I've d
The problem was that the RFC had been updated past where the code was, AFAIK
you can't branch a wiki page, can you? That's what needed branching... unless
you mean to create a v1.1 page and a v1.2 page, which is basically what I've
done...
> -Original Message-
> From: Pierre Joye [mail
2012/10/20 Derick Rethans
> There is nothing wrong with being verbose. PHP has always been verbose,
> which IMO is a strong point of the language as it makes everything a lot
> easier to search for.
>
There is a confusion between being verbose and being explicit.
PHP syntax is explicit. Verbosit
Hi!
> Class A created property accessor $z that you can not set. Class B can
> extend me just fine, but they can not alter that basic rule that I laid
> out for my and all my children's property accessor $z: You can not set it.
I'm fine with the idea of methods that are not overrideable, even th
2012/10/20 Nikita Popov
> Could you maybe explain where exactly "const" would be used?
>
Well "const" and "read-only" have the exact same meaning. You can replace
one by the other. So why create a new keyword?
> Please
> don't forget that we do not use your "foo:bar" syntax, so where would
>
Nikita brought up a good point:
There aren't all that many scripts that use final methods, which could very
well be the same fate for final property accessor methods.
Due to the very possible unpopularity of whatever magic syntax/keyword we
could potentially come up with, we *could *alternatively
On Sat, Oct 20, 2012 at 1:06 AM, Clint Priest wrote:
> Hey everyone, seems like the conversations have died down and I've attempted
> to go back through all of the emails and produce a 1.1 -> 1.2 document which
> summarizes what I believe are decided, being debated, issues, todos, etc.
>
> Pierr
Nikita, there appears to be a slight misunderstanding. You're initial email
was worded in a way that I presumed you were attacking the final keyword
entirely, not just final methods. You are correct in that many PHP
frameworks don't have final *functions*.
My pushing for the read-only functionalit
On Sat, Oct 20, 2012 at 1:07 AM, Clint Priest wrote:
> I had thought of a deviation on some of the ideas presented to get rid of
> read-only/write-only while still keeping the ability to maintain their
> effect, if we so decide that the feature is wanted. Here it is:
>
> class TimePeriod {
>
On Sat, Oct 20, 2012 at 11:31 AM, Jazzer Dane wrote:
> The final keyword is used, especially in sizable OOP applications. Claiming
> it supposedly isn't used very often anymore - even if it were true - is not
> an excuse to exclude the "read-only"-esque functionality in this RFC.
Firstly, I didn't
I'll agree with you in regards to your analysis of Clint's proposed syntax.
In terms of your questioning the idea around "read-only", this is how I
think about it:
Class A created property accessor $z that you can not set. Class B can
extend me just fine, but they can not alter that basic rule th
Hi!
> get() { return $this->Hours; }
> final set NULL;
It looks like some unobvious piece of magic - what exactly "set NULL"
means? There's no obvious parsing of this thing for somebody that
doesn't already know what the magic means. I'd rather have people
implement a method throw
The usage of the syntax in C# is moderately unimportant. This is a
different language, and property accessors are part of numerous languages -
not just C#. That being said, it's not that big of a deal, as it seems that
most people are in a consensus that we do not want to to be adding any sort
of r
On Tue, 16 Oct 2012, J. Adams wrote:
> I agree. VBulletin rules. It also permits voluntary participation rather than
> getting every email for ever conversation. Should you prefer to get everything
> via email, I believe it is possible to sync VBulletin with a mailing list.
If everybody would jus
On Sat, 20 Oct 2012, Amaury Bouchard wrote:
> read-only => final set null;
> It begins to be verbose.
There is nothing wrong with being verbose. PHP has always been verbose,
which IMO is a strong point of the language as it makes everything a lot
easier to search for.
cheers,
Derick
--
ht
On Sat, Oct 20, 2012 at 9:29 AM, Amaury Bouchard wrote:
> read-only => final set null;
> It begins to be verbose.
>
> As I said many times, why don't you want to use the "const" keyword? It
> already exists and is pretty well understood by everybody.
Could you maybe explain where exactly "const"
read-only / write-only keywords
"no equivalent replacement has been suggested" => ouch
read-only => const
write-only => shouldn't exists. A write-only accessor is just a method
disguised in property.
It's not a good idea to allow:
$obj->prop = 3;
when the meaning is:
$obj->meth(3);
20
read-only => final set null;
It begins to be verbose.
As I said many times, why don't you want to use the "const" keyword? It
already exists and is pretty well understood by everybody.
2012/10/20 Clint Priest
> I had thought of a deviation on some of the ideas presented to get rid of
> read
28 matches
Mail list logo
