2013/5/28 Sebastian Krebs
>
> And in your example you have to know, that you are "manipulating" a
> variable :?
>
>
Sure. But my example's goal was to show the idea of Lars.
Using the "final" keyword on variables would allow to manipulate variables
and "constant variables", without the need to kn
2013/5/28 Sebastian Krebs
>print($$b);
>>
>
> print(constant($b));
>
It's definitely different. In your example you have to know that you are
manipulating constants only.
2013/5/28 Maciek Sokolewicz
> It’s a good idea in general but what about having it for variables as
>> well? Could open interesting possibilities for an optimizer.
>>
>> final $foo = "str";
>> $foo = "bar"; // bails out
>>
>> Don't we already have that? It just has a different name: constants.
2013/4/29 Stas Malyshev
> I agree. If your code can handle the problem, it should not throw. If it
> throws, the control should not go back there, since the code already
> gave up and declared it can not continue doing whatever it was doing.
> Exceptions are meant to handle exceptional situations
ack".
2013/4/29 Camilo Sperberg
>
> On Apr 28, 2013, at 17:27, Julien Pauli wrote:
>
> > On Sat, Apr 27, 2013 at 3:56 PM, Amaury Bouchard
> wrote:
> >
> >> 2013/4/27 Ferenc Kovacs
> >>
> >>> please don't reuse the co
2013/4/27 Daniel Macedo
> Sorry but I disagree, I think you're approaching try-catch wrong.
>
> You shouldn't have a try-catch that *can* continue on the next line after
> the throw.
> What you should do is have decoupled code that handles _their own
> exceptions_ nicely and either cleans up afte
2013/4/27 Ferenc Kovacs
> please don't reuse the continue keyword for it.
>
> There are a bunch of code out there where which uses exceptions in a loop
> context.
> For example you have a retry counter decremented in a loop and you catch
> the exceptions and retry until the retry limit is reached
2013/4/26 Andreas Heigl
> try {
> $foo = $bar->getObject();
> $foo->doSomething()
> } catch(Exception $e) {
> continue // Or whatever shall be used
> }
>
> When $bar->getObject throws an Exception no $foo is set. So the next
> line will result in a "PHP Fatal error: Call to a member
I will answer, as the idea came from Pierrick Charron and I :-)
Sometimes, you call functions (or methods) and you know they can throw some
exceptions. But you don't want to stop all computations just because one of
them raised an exception. Maybe you just want to log it, and go to the next
call.
2013/1/11 dukeofgaming
> I have a question, maybe it is dumb: why not those opposed to using
> annotations just... refrain from using them?
>
As I said in a previous message:
« (...) providing annotations as it is proposed will make them a core
feature of the language. It will be perceived like
2013/1/10 Rafael Dohms
> In my humble opinion, if your only "argument" is a -1, the don't be part of
> the discussion, but rather be a vote when (and if) the RFC goes to a vote.
>
> There are 2 moments to express yourself: the discussion, the vote.
>
> In the discussion phase I believe opinion sh
2013/1/9 Anthony Ferrara
> Stas,
>
> Would you shut up with this rhetoric already? All it does is show that
> you're completely and utterly out of touch with the reality of modern
> development.
>
> Frankly, I'm getting sick and tired of seeing these recurring themes of
> "PHP is not java" and "I
Nobody wants to turn PHP into Java.
But, even if I agree for generics (or templates), I would like to know
where is the border line.
Classes, exceptions, interfaces, traits, type hinting in parameters => OK
Type hinting in object properties, type hinting of returned values, type
templating => KO?
, anyone disagree?
>
> > -Original Message-
> > From: Levi Morrison [mailto:morrison.l...@gmail.com]
> > Sent: Sunday, October 21, 2012 10:26 AM
> > To: Amaury Bouchard
> > Cc: Nikita Popov; Clint Priest; internals@lists.php.net
> > Subject: Re: [PHP-DEV] [
2012/10/21 Levi Morrison
> I would like to point out that in my mind `const` and `read-only` are
> not necessarily the same thing. Read-only means that from outside the
> class it cannot be modified; the internal class can change it whenever
> it wants. Const means that once the value is set it
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
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
>
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
2012/10/17 Stas Malyshev
> No, you don't get an error. You'd get an error in compiled language. In
> dynamic language, your client gets an error when his site is launched
> and instead of happy launch his users get white screens. To avoid that,
> you'd need to add checks - or just ship it as is a
2012/10/16 Rasmus Lerdorf
> The rule in PHP for any sort of type hinting is that it is only done for
> non-coercable types. In cases where there is simply no way to recover
> from passing the wrong type, it is good to catch it as early as
> possible. Extending this to also cover scalar coercable
2012/10/16 Clint Priest
> In this regard, I have yet to see any proposal that is as clear or concise
> as public read-only $abc. What is the big problem with adding read-only
> and write-only keywords? Once they are in the language they could be
> expanded to plain properties.
public:const $a
2012/10/16 Stas Malyshev
> Also, the fact is that other dynamic languages do not
> have strong typing. It may be they just aren't smart enough to recognize
> everybody needs it - or there may be a reason why it doesn't happen. I
> think there is a reason
>
> > Doing the same for object properties
2012/10/16 Stas Malyshev
> >> public DateTime $date;
> >
> > This is *real* progress, even if under the hood all it does is wrap
>
> I think it's a movement in wrong direction. Again, it is an attempt to
> make PHP a strongly typed language, which would not work well in a
> dynamic language like
owards any other option.
>
> That being said, I wouldn't contest to hearing - in more detail - your
> reasoning behind why we should use it instead of the current syntax.
>
>
> On Tue, Oct 16, 2012 at 12:39 AM, Amaury Bouchard wrote:
>
>> 2012/10/15 Clint Priest
>
2012/10/15 Clint Priest
> Also, your "should be valid" statement implies that you feel properties
> and accessors are the same and they are not, internally. When a class
> attempts to implement an interface a "function check" is done and since
> there is no __getXX() function defined it would fa
il.com [mailto:amaury.bouch...@gmail.com] *On
> Behalf Of *Amaury Bouchard
> *Sent:* Sunday, October 14, 2012 3:23 AM
> *To:* Clint Priest
> *Cc:* Nikita Popov; Benjamin Eberlei; internals@lists.php.net
>
> *Subject:* Re: [PHP-DEV] [PHP-DEV [RFC] Property Accessors v1.2
>
>
C#, but I think PHP is an opinionated language and we can do
our own choices (see how namespaces work in a very different way from C++
namespaces, for example).
As you point out, __get() implies the choice has already be done. So I shut
up now :-)
2012/10/14 Clint Priest
>
>
> -
2012/10/13 Clint Priest
>Interfaces are used to define what methods must be present, properties
> are not allowed.
>
> ** **
>
> Yes, so no one should be correct, right?
>
> I mean, yes the first declaration implies some code; but for the
> interface, it's still a property definition.
.
> *From:* amaury.bouch...@gmail.com [mailto:amaury.bouch...@gmail.com] *On
> Behalf Of *Amaury Bouchard
> *Sent:* Saturday, October 13, 2012 5:06 AM
> *To:* Nikita Popov
> *Cc:* Benjamin Eberlei; Clint Priest; internals@lists.php.net
>
> *Subject:* Re: [PHP-DEV] [PH
2012/10/13 Nikita Popov
> interface Foo {
> // this is okay
> public $abc { get; set; }
>
> // this is invalid
> public $abc;
> }
>
Sorry, I missed something. Why the first should be correct but not the
second one?
For me it's exactly the same thing.
Le 12 oct. 2012 10:37, "Bernhard Schussek" a écrit :
> > As I said, both syntaxes can work together. For example:
> > public:protected $a {
> > get() { return ($this->_prefix . $this->_a); }
> > set($val) { $this->_a = substr($val, 1); }
> > }
>
> A shortcoming of this syntax is that i
2012/10/12 Clint Priest
> I guess I didn’t see any other support for it from others
>
Well, I get some bad replies (mainly from Andrew), but good ones too. Some
people (like Matthew) said it was an elegant syntax...
> and it is a subset of what the RFC I am proposing would encompass
>
Yes
You really don't want to even think about my idea? It's complementary on
some aspects, you know.
2012/10/11 Clint Priest
> Rather than go to the trouble of finding a reasonable way to hold a vote
> on these issues, is there anyone against the following changes:
>
> 1) Eliminate the ability for a
Hi,
This summer (july 15) I did another proposal, which has some connections
with yours.
For the main usage of getters/setters, my guess is that we need separate
read/write visibilities. Your RFC goes beyond that, but I think both are
complementary.
Most of the time, we write getters/setters to e
Sounds to me like aspect-oriented programming, applied to object construction.
Take a look at: https://github.com/AOP-PHP/AOP
2012/9/18 Rasmus Schultz :
> Hey,
>
> I'm going to make this brief, because I suspect a lot of people are going
> to jump at the opportunity to cry bloody murder when I su
2012/9/10 jpauli :
> Based on our recent discussion on #pecl , I'd like we clarify what we
> think is a "BCB" (Backward Compatibility Break) as well as what "only
> minor BC breaks" could mean.
> Stas' recent topic on internals "On BC and interfaces" may serve as a
> reflection basis.
> As our rele
2012/9/2 Sherif Ramadan
> To clarify, this particular functionality you're using as an example
> "array_unshift" really isn't specific to the internal implementation
> of hashtables in PHP. That is to say that this side-effect you're
> describing is specific to that function and not necessarily
>
Hi all,
I have a question about the internal implementation of PHP's hashtables. I
did some researches, but I didn't find the answer.
Here is an example of what I would like to understand.
Start by creating an array:
$a = array();
Fill it, using implicit and explicit keys:
$a[] = 'cc';
$a[1]
2012/8/6 Stas Malyshev
> Exceptions are different from PHP errors. For example, if you try to
> open a file and the file isn't there, throwing exception is a very
> annoying behavior (yes I know some languages do that, IMO it's wrong).
> The reason is that it's pretty normal and within normal set
set { $this->str = trim($value, "«»"); }
}
}
2012/7/24 André Rømcke
> On 7/23/12 12:38 PM, "Amaury Bouchard" wrote:
>
> 2012/7/23 André Rømcke
>
>> I think these two proposals can be synced up, what if:
>>
>> public r
2012/7/23 André Rømcke
> I think these two proposals can be synced up, what if:
>
> public readonly $a;
>
> Is shorthand for:
>
> public $a { get; protected set; }
>
>
> And when no function is defined, no function overhead is added.
>
Well, this code:
public read-only $a;
introduces
ons targeted by the proposal).
I would like everybody give 5 minutes to this idea [1] :-)
[1] : http://37signals.com/svn/posts/3124-give-it-five-minutes
2012/7/21 Matthew Weier O'Phinney
> On 2012-07-16, Amaury Bouchard wrote:
> > --f46d0446312cc5e06104c4f42161
> > Content
2012/7/20 Alex Aulbach
> PS: And if without brackets should be forbidden.
>
If I wanted a coding style-constrained language, I would use Python.
According to Rasmus' recent talk, a large part of PHP success came from its
focus on web ecosystem, on what hosting ISPs are effectively needing.
http://talks.php.net/show/supepi/6 (but it's better when you hear Rasmus
telling it)
2012/7/20 Andrew Faulds
> Whilst I feel some sympathy for you, I
2012/7/19 Reeze
> 在 2012年7月19日星期四，下午6:45，Rune Kaagaard 写道：
>
> > +1 for the consistency of it. It's surprising that:
> >
> > if ($foo)
> > return $bar;
> > else
> > return 42;
> >
> > works and:
> >
> > try
> > maybe_dangerous();
> > catch(Dynamite $e)
> > handle_error();
> >
> >
>
> Ther
Seems a lot like another syntactic sugar.
Like in Lua, where you can write
obj:method(12)
instead of
obj.method(obj, 12)
But OOP-like syntax on non-object data is still weird. The question about
data manipulation behavior (is it a pointer like other objects or is it a
scalar like existing a
got it was read-only and I forgot to remove it...
So, I guess it should be like that:
protected $a {
private set;
}
Then, try to read this code aloud. I'm really not sure it's better than a
simple "protected:private $a;", which could be read like "protect
aulds
> How much syntactic sugar do we really need? Why add two ways to do
> something?
>
> On 16 July 2012 16:24, Amaury Bouchard wrote:
> > 2012/7/16 Nikita Popov
> >
> >> I'm not sure I really understand what this adds over the existing
> >> get
2012/7/16 Nikita Popov
> I'm not sure I really understand what this adds over the existing
> getter/setter proposal. read-only and write-only should cover the most
> common cases. If you do need visibility control, it is possible too:
>
> public $property {
> get { ... }
> protected set {
It could be useful (given the example of Java usage).
But still, if the goal is to have read-only attributes, I think my proposal
(separate reading and writing visibilities) is more precise and powerful.
2012/7/16 Ferenc Kovacs
> Hi,
>
> The recent
> http://www.mail-archive.com/internals@lists.p
here is some
obvious connections).
On Sun, Jul 15, 2012 at 12:46 PM, Amaury Bouchard wrote:
>
>> Hi,
>>
>> Here is an RFC proposal about a syntax extension for PHP. The purpose is
>> to
>> manage precisely the visbiliy of attributes, by separating reading and
>
syntax. It shouldn't be in the same RFC.
More, the proposed "read-only" and "write-only" keywords are less precise
and powerful than what I'm suggesting.
I would be happy to discuss all that with you guys.
Best regards,
Amaury Bouchard
[1] : https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented
harron >wrote:
> >
> >> No problem when you'll come in Montreal ! If you need any help don't
> >> hesitate.
> >>
> >> Pierrick
> >>
> >> On 29 June 2012 14:27, Amaury Bouchard wrote:
> >>
> >> > Yes, guys. I totally und
Yes, guys. I totally understand your point. As I said, I had this idea in a
dreamed context (good or bad dream? I don't know).
But still, I think it's intellectually interesting, even if it's not a good
concept for PHP. :-)
Pierrick, I owe you a beer ;-)
Le 29 juin 2012 19:06, "Pierrick Charron"
Hello everybody,
It's the first time I write on the internals mailing-list, so let me
introduce myself quickly. I'm a french and canadian CTO, working in Paris.
I lead some PHP projects (mainly the Temma framework and FineFS data
replication system).
I begin to learn PHP's internal engine, backed
56 matches
Mail list logo
