Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Victor Bolshov]

On Sat, Mar 5, 2022 at 14:26, Kris Craig  wrote:

Specifically, I would direct this question to
Pierre and Viktor:  Do you believe that "Arrest Dictator Putin" is
appropriate for the PHP homepage?


As a Russian who fled his country because of arising concerns over Mr. 
Putin's regime, I find any words against him, appropriate. I'm a 
pacifist but I probably would try to kill him if I was given a chance.


Speaking about how appropriate "Arrest Putin" would be *on the PHP home 
page*, I'd say no, because I see how many different people have 
gathered here. We see that even Ukranian flag on PHP homepage is going 
to cause tensions (what about Iraq & Viet Nam?).


Starting this discussion, I had in mind the "sanity again madness" 
mentality. I even feel sorry now for how this thread brings so many 
disagreements and sol little compromise, so many emotions and so little 
reason. I still think though that in times like this, stating something 
like "PHP is against war" is very timely, and it is something we can 
agree to, without destroying any connections within community.

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Victor Bolshov]

Exactly. What context are we not understanding? Condemn war. Peace is 
the only side PHP is about to take, it is ALWAYS good to be for peace 
and against war. Is this going to separate the PHP community in any 
way? No. Just - NO. Easy as that.


On Fri, Mar 4, 2022 at 09:25, Lynn  wrote:
On Fri, Mar 4, 2022 at 9:17 AM Kalle Sommer Nielsen > wrote:


 Den fre. 4. mar. 2022 kl. 01.18 skrev Lynn >:

 > Not making a statement is also making a statement.

 I disagree, assuming a stance without understanding the context is 
insanity




What context are we not understanding?

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Victor Bolshov]

Even a simple sign of solidarity against the war is important, if this 
is something community can agree to, without having to fall into mutual 
hatred.


I personally would love to see a clear support for Ukraine, but if that 
will be causing endless debate I would give up on this in favor of a 
general anti-war statement, at least until it is clear to the vast 
majority of smart people here that Putin is a threat for humanity and 
civilization, and I am NOT exaggerating. Ukraine is currently the 
civilized world's outpost that is giving their lives to oppose madness 
and chaos.


On Thu, Mar 3, 2022 at 10:31, Sergey Panteleev  
wrote:

Hey all,

I'd like to add my 2c:

I agree that php.net is not the right place to express our personal 
citizenship.
It's better to use Twitter, Facebook, or another social network for 
these purposes.



If you believe that the PHP community is obliged to show solidarity 
on the php.net,

and not every person personally,
I suggest that instead of a banner we release a News on the main page.


Why is this important? There are a lot of PHP developers in Russia.
A lot of them, sadly, have been brainwashed by Putin's propaganda.
They still must have a lot of respect to PHP authors and creators.
Seeing that these people, who have their respect, are against the 
war and for the freedom of Ukraine, might have an impact.


I can not answer for all Russian developers, but I can judge by 
myself and my social circle:
we're against the war, "military operation" or any other aggression, 
whatever you want to call it.


Also, colleagues from the IT industry have drafted an open letter to 
the national government [1-2].


In addition to highlighting the problem, we can also add these links:
in this case, developers from Russia will see, that not only people,
who have their respect do not support the war, but also their fellow 
countrymen.


[1] 

[2] 



—
wbr,
Sergey Panteleev

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Victor Bolshov]

Just one more thing: as of yesterday, in response to western sanctions 
and supplies of letal arms to Ukraine from EU countries, Putin has 
ordered Russian nuclear forces to switch to a special alert regime, 
which means they will be ready to strike at any moment. Anything that 
can help stop this insanity, is welcome, IMO.


On Wed, Mar 2, 2022 at 17:33, Victor Bolshov  
wrote:
This is going to cause debate, I was sure about it. And if the 
community agrees at least to state "NO WAR", that is already 
something.


To provide more context on Putin's propaganda: he has been 
consistently putting more and more restrictions on nearly each and 
every independent media. I can only name one nation-wide 
radio-station - "Echo of Moscow", which has been deprived of their FM 
frequency as of today. There is 1 printed nation-wide newspaper 
"Novaya Gazeta" (editor-in-chief Dmitry Muratov was awarded Nobel 
Prize this year). Other noticeable media mostly have been claimed 
"foreign agents" which heavily impacts their operation. To name one 
thing, they have to have a preamble to every publication with a long 
disclaimer "this material was published by a foreign agent (actually 
much longer a utterly bureaucratic crap)". Also, other media are only 
available on internet. The russian government controls internet 
through their puppet RosKomNadzor which can block any website in 
Russia without even the need for a court hearing or an court order. A 
big radio-station "Silver Rain" have closed all their news and 
political shows as of today, because it's no longer allowed to say a 
word of truth in Russia.


The world has seen these patterns before, and we all know what the 
consequences of good people remaining silent were.




On Wed, Mar 2, 2022 at 17:12, Kalle Sommer Nielsen  
wrote:
Den ons. 2. mar. 2022 kl. 14.51 skrev Marco Pivetta 
mailto:ocram...@gmail.com>>:
 Please GTFO: we don't need more of Putin's propaganda over here, 
as they're

 busy enough with butchering civilians over there.


I heavily agree with this matter, the PHP project should remain
neutral. Seeing this thread already makes me dread the idea of even
considering such, even if it is done with the purest of intentions.


Big -1 from me (and to all future proposals of similar political 
matter)


--
regards,

Kalle Sommer Nielsen
ka...@php.net <mailto:ka...@php.net>

Re: [PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Victor Bolshov]

This is going to cause debate, I was sure about it. And if the 
community agrees at least to state "NO WAR", that is already something.


To provide more context on Putin's propaganda: he has been consistently 
putting more and more restrictions on nearly each and every independent 
media. I can only name one nation-wide radio-station - "Echo of 
Moscow", which has been deprived of their FM frequency as of today. 
There is 1 printed nation-wide newspaper "Novaya Gazeta" 
(editor-in-chief Dmitry Muratov was awarded Nobel Prize this year). 
Other noticeable media mostly have been claimed "foreign agents" which 
heavily impacts their operation. To name one thing, they have to have a 
preamble to every publication with a long disclaimer "this material was 
published by a foreign agent (actually much longer a utterly 
bureaucratic crap)". Also, other media are only available on internet. 
The russian government controls internet through their puppet 
RosKomNadzor which can block any website in Russia without even the 
need for a court hearing or an court order. A big radio-station "Silver 
Rain" have closed all their news and political shows as of today, 
because it's no longer allowed to say a word of truth in Russia.


The world has seen these patterns before, and we all know what the 
consequences of good people remaining silent were.




On Wed, Mar 2, 2022 at 17:12, Kalle Sommer Nielsen  
wrote:
Den ons. 2. mar. 2022 kl. 14.51 skrev Marco Pivetta 
mailto:ocram...@gmail.com>>:
 Please GTFO: we don't need more of Putin's propaganda over here, as 
they're

 busy enough with butchering civilians over there.


I heavily agree with this matter, the PHP project should remain
neutral. Seeing this thread already makes me dread the idea of even
considering such, even if it is done with the purest of intentions.


Big -1 from me (and to all future proposals of similar political 
matter)


--
regards,

Kalle Sommer Nielsen
ka...@php.net 

[PHP-DEV] PHP Community to support Ukraine and help to stop Russian agression

[Victor Bolshov]

Hello internals.

In these dark days for humanity, we as people of civilization, people 
of sanity, kind and caring people with children and families - we have 
to speak up, loud and clear, in support for Ukraine. To stop Russian 
aggression.


I suggest to add Ukranian flag and a supportive anti-war disclaimer to 
the header of php.net website.


Why is this important? There are a lot of PHP developers in Russia. A 
lot of them, sadly, have been brainwashed by Putin's propaganda. They 
still must have a lot of respect to PHP authors and creators. Seeing 
that these people, who have their respect, are against the war and for 
the freedom of Ukraine, might have an impact.


This is not the time to "stay away from politics", we are experiencing 
an attack on humanity itself. Take example from 
 and their clear statement.


Say NO to war!

Re: [PHP-DEV] [VOTE] Deprecate dynamic properties

[Victor Bolshov]

The way I see it, it might look similar to strict_types opt-in, but 
only on the surface. The amount of changes needed to make legacy code 
compliant with strict_types directive, would be tremendous, also there 
would be no simple one-size-fits-all solution like the 
#[AllowDynamicProperties]. In that sense, these two are hardly 
comparable.


I agree with the change (not that I have a voting karma, just 
watching). I also agree with Andreas Heigl saying that at certain point 
changes like this probably should happen, and regardless of exactly 
when, it is going to cause debate and complaints, but we as community 
should probably prefer having a long deprecation cycle for smoother 
transition, which is why the suggested timeline is IMO good (that is, 
if the community represented by core devs will vote for this RFC).


Opt-in strategy - #[DenyDynamicProperties] - for a change like this 
would effectively do nothing. I personally would be against this change 
at all then.


Many thanks to the PHP team from userland, also for letting anyone 
voice their thoughts and concerns on important matters!


Regards,
Victor Bolshov,
Software developer

On za, nov 13, 2021 at 08:26, Peter Bowyer  
wrote:
On Sat, 13 Nov 2021, 00:14 Christoph M. Becker, <mailto:cmbecke...@gmx.de>> wrote:



 Offering an
 opt-out of dynamic properties or some switch to disable the 
deprecation

 would not help in that regard.



Given this is a big change to the way PHP has behaved for decades I 
did
wonder why the RFC didn't propose an opt-out of dynamic properties 
rather
than opt-in, preserving the long-term language behaviour. So thanks 
for

covering that.

I think you and the PHP internals community will be surprised by how 
widely
used dynamic properties are. I read through a handful of WordPress 
plugins
we have installed and found a few. And in my own where I'm using a 
named

class instead of an array.

I work with modern framework based code most of the time and I find 
it easy

to forget what is out there as quintessential or traditional PHP code.

Whether we have #[AllowDynamicProperties] or #[DenyDynamicProperties] 
one

set of PHP users is going to be doing a find & replace across their
codebase.

From a DX perspective I'd rather have #[DenyDynamicProperties] as 
it's like

declaring strict_mode and opt-in.

Either way are the planned engine changes feasible, as the feature of
dynamic properties stays in the language but toggled off/on per class?

Peter

Re: [PHP-DEV] Honour the Default Value of 'return' Statement According to the Function Signature

[Victor Bolshov]

IMO this feature would contradict with the Single Responsibility Principle. 
Type hints are for type hinting, not for value hinting. Cheers.

Sent from Mailspring 
(https://link.getmailspring.com/link/4d67851f-de69-45d9-9db1-54b16845e...@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F=aW50ZXJuYWxzQGxpc3RzLnBocC5uZXQ%3D),
 the best free email app for work
On Mar 11 2021, at 10:51 am, Hamza Ahmad  wrote:
> Hi Rowan,
> Thanks for the response. Luckily, you razed the question that I thought about 
> after posting the first request.
> My idea develops on respecting both return type hints and union types. The 
> current implementation of empty return does not respect the function 
> signature. As I have mentioned in the first message that empty return returns 
> null regardless of the return type set, I propose that an empty return may 
> return the defaults of types i.e. an empty string if the type is string, an 
> empty array if the type is array, zero if the type is int etcetera. I have 
> also noted that in a void typed function, an empty return may return nothing 
> and just end the execution.
> The current implementation of empty return is only favourable for mixed type. 
> In other words, when the return type is mixed, an empty return may return 
> null. Otherwise, it should respect the declared return type.
> After the release of union types, there emerges a question regarding the 
> selection of default return value. To solve this problem, the type on the 
> very right side will be used.
> Now, I come to your question, Rowan. As of today, only false and null 
> literals are supported. If both assist in error handling, why does empty 
> return always returns null?
> I tested this code on shell.
> var_dump($a=(function():string|false{return;})());
> It produced:
> Fatal error: A function with return type must return a value in php shell 
> code on line 1.
> Here comes the inconsistency. To resolve the problem, I suggest to respect 
> the literals first. If literals are not found, respect the first type on the 
> right side.
> Moreover, only two standalone literals, false and null, will be supported. 
> Otherwise, the literal should be one of the types specified. If multiple 
> literals are specified, it will throw an error of multiple literals. The 
> literal can be a simple literal, such as, "unknown" 0, and a constant 
> expression, like self :: MSG_UNKNOWN. It will help maintain the 
> multi-language scripts.
> I hope I have been able to make my stance clear.
> Best
> Hamza Ahmad
>
> -Original Message-
> From: Rowan Tommins 
> Sent: Thursday, March 11, 2021 1:45 PM
> To: internals@lists.php.net
> Subject: Re: [PHP-DEV] Honour the Default Value of 'return' Statement 
> According to the Function Signature
>
> On 11 March 2021 03:37:52 GMT, office.hamzaah...@gmail.com wrote:
> > >function get_nationality_string(int $country_code) : string | "unknown"
> >{
> > return;
> >};
>
> If I understand you correctly, your idea is that the "return;" here would be 
> treated automatically as "return 'unknown';" I think that's an interesting 
> idea, although I can't immediately think of a situation where I'd use it.
> My main concerns are with the syntax:
> - Firstly, specific literals aren't currently allowed in return types, and 
> allowing them would have other implications. Three exception is "false", 
> which is allowed because of its common use as an error code, including in 
> many internal functions.
> - Secondly, it could be ambiguous which is intended to be the default value, 
> if the return type was something like int|"yes"|"no"
>
> Perhaps the default return value would need to be specified separately from 
> the return type somehow?
> Regards,
> Hi Hamza,
>
> Welcome to the list, and thanks for sharing this idea.
> --
> Rowan Tommins
> [IMSoP]
>
> --
> PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: 
> https://www.php.net/unsub.php
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: https://www.php.net/unsub.php
>

Re: [PHP-DEV] Proposal For Return-If / Early Return / Guard Clause Syntax

[Victor Bolshov]

Hi internals,

I think it's just as good to write:
if ($condition) return $retval;
Yes, there are subtle semantic differences the new syntax would emphasize, but 
it doesn't feel like it justifies it. New syntax also means the need to support 
it, for IDEs and other tools, static analysis tools, code-style tools - and all 
that for a very tiny benefit, if any.
Cheers,
Victor

Sent from Mailspring 
(https://link.getmailspring.com/link/85c8412b-b04a-4853-8c4c-e270fcb35...@getmailspring.com/0?redirect=https%3A%2F%2Fgetmailspring.com%2F=aW50ZXJuYWxzQGxpc3RzLnBocC5uZXQ%3D),
 the best free email app for work
On May 10 2020, at 5:49 pm, Ralph Schindler  wrote:
> Hi! # Intro I am proposing what is a near completely syntactical addition 
> (only change is to language.y) to the language. The best terminology for this 
> syntax is are: `return if`, "return early", or "guard clauses". see: 
> https://en.wikipedia.org/wiki/Guard_(computer_science) Over the past few 
> years, I've seen a growing number of blog posts, conference talks, and even 
> tooling (for example code complexity scoring), that suggest writing guard 
> clauses is a good practice to utilize. I've also seen it more prevalent in 
> code, and even attempts at achieving this with Exceptions (in an HTTP 
> context) in a framework like Laravel. see abort_if/throw_if: 
> https://laravel.com/docs/7.x/helpers#method-abort-if It is also worth 
> mentioning that Ruby has similar features, and I believe they are heavily 
> utilized: see: 
> https://github.com/rubocop-hq/ruby-style-guide#no-nested-conditionals # 
> Proposal In an effort to make it a first class feature of the language, and 
> to make the control flow / guard clause
s more visible when scanning code, I am proposing this in the syntax of adding 
`return if`. The chosen syntax is: return if ( if_expr ) [: 
optional_return_expression] ; As a contrived example: function 
divide($dividend, $divisor = null) { return if ($divisor === null || $divisor 
=== 0); return $dividend / $divisor; } There is already a little discussion 
around the choice of order in the above statement, the main take-aways and (my) 
perceived benefits are: - it keeps the intent nearest the left rail of the code 
(in normal/common-ish coding standards) - it treats "return if" as a 
meta-keyword; if must follow return for the statement to be a guard clause. 
This also allows a person to more easily discern "returns" from "return ifs" 
more easily since there is not an arbitrary amount of code between them (for 
example if the return expression were after return but before if). - it has the 
quality that optional parts are towards the end - is also has the quality that 
the : return_expression;
 is very symmetrical to the way we demarcate the return type in method 
signatures "): return type {" for example. - has the quality of promoting 
single-line conditional returns # Finally One might say this is unnecessary 
syntactic sugar, which is definitely arguable. But we do have multiple ways of 
achieving this. Of course all of these things should be discussed, I think 
sub-votes (should this PR make it that far) could be considered. The PR is 
located here: https://github.com/php/php-src/pull/5552 As mentioned, some 
discussion is happening there as well. Thanks! Ralph Schindler PS: since 
implementing the ::class feature 8 years ago, the addition of the AST 
abstraction made this kind of syntactical change proof-of-concept so much 
easier, bravo! -- PHP Internals - PHP Runtime Development Mailing List To 
unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] An implementation of a short syntax for closures

[Victor Bolshov]

+1 - think everybody'd want their functions to be searchable and searching
for complex patterns like (function)|(\|\=\) would really be a headache.
Btw, am I the only one to whom the proposed syntax seems kinda hieroglyphic?

2011/8/4 Antony Dovgal t...@daylessday.org

 On 08/04/2011 04:39 PM, Lazare Inepologlou wrote:

  ... ( $x ) =  $x + 1 for example would be ambiguous if used in an array
 definition, but is otherwise the best in terms of readability.


   ... people wanted an easy way to grep for function declarations



 A new and unique operator (like the |=  I have proposed) is a solution
 that works because:


 Please stop that, it's not funny anymore.

 --
 Wbr,
 Antony Dovgal
 ---
 http://pinba.org - realtime profiling for PHP


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Traits expecting interfaces implicitly leads to expensive runtime checks

[Victor Bolshov]

Personally, I believed that traits are a *compile time injection* to a
class, so that at runtime a class behaves completely as it would if trait
methods were implemented directly in the class. That said, everything like
trait requirements for a certain interface, should be done at compile time
and constructions like abstract foo(); in a trait serve that purpose. IMHO.

2010/12/10 Stefan Marr p...@stefan-marr.de

 Hi Nathan:


 On 09 Dec 2010, at 23:42, Nathan Nobbe wrote:
  What I'm getting at is the scenario when a trait is designed to be used
 in
  concert with the class in which it is being used.  In this case the trait
  expects certain functions to be available on the class in which it is
 used
  with.  If the methods aren't there (or checked for at runtime) a fatal
 error
  is raised.
 
  A quick example
  ?php
  class A {
   use AHelper;
 
   function blah() {}
  }
 
  trait AHelper {
   function meh() {
 // hoping we get used w/ instances of A ...
 return $this-blah() * 5;
   }
  }
 
  class B {
   use AHelper;
 
   /// waiting for a runtime error if blah() is ever called ..
  }
  ?
 
  Do you see what I mean?
 No, do not really see what you are getting at.

 How is your approach using the instanceof checks (from the first mail)
 different from changing AHelper to require blah() by stating this
 requirement using an abstract method definition?
 For the trait it is not important where that method is implemented, it just
 has to be in the final composed class.

 So, why don't you want the following trait?

 trait AHelper {
  abstract function blah();

  function meh() {
   // hoping we get used w/ instances of A ...
   return $this-blah() * 5;
  }

 }

 You want to avoid the fatal error during runtime, right?

 Do you prefer dynamic checks over compile time checks?

 Best regards
 Stefan

 --
 Stefan Marr
 Software Languages Lab
 Vrije Universiteit Brussel
 Pleinlaan 2 / B-1050 Brussels / Belgium
 http://soft.vub.ac.be/~smarr
 Phone: +32 2 629 2974
 Fax:   +32 2 629 3525


 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
С уважением,
Виктор

Fwd: [PHP-DEV] deprecation status of $str{42} versus $str[42], revisited

[Victor Bolshov]

-- Пересланное сообщение --
От кого: Victor Bolshov crocodil...@gmail.com
Дата: 23 сентября 2010 г. 8:48
Тема: Re: [PHP-DEV] deprecation status of $str{42} versus $str[42],
revisited
Кому: Chris Stockton chrisstockto...@gmail.com


Personally, I use the syntax $str{1} since long time before 2006, and when
it comes to that, I always remember {} but always forget []. It's just a
habit. Definitelty, I would prefer {} syntax to stay and not to issue any
kind of error.

2010/9/23 Chris Stockton chrisstockto...@gmail.com

Hello,

 On Wed, Sep 22, 2010 at 2:34 PM, Philip Olson phi...@roshambo.org wrote:
  Greetings geeks,
 
  Also, Andi mentioned[1] the possibility of optimizing {} for string use
 (the original intent) in which case keeping {} would be wise.

 It was over two years ago I commented on my interest in keeping {} and
 offering/exploring the potential to performance or feature
 improvements to the syntax, I still have the same opinion personally.

 -Chris

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
С уважением,
Виктор



-- 
С уважением,
Виктор

Re: [PHP-DEV] Strict typing

[Victor Bolshov]

 If there were
 only two options left on earth, strict typing and strict+auto-conversion,
 I'd vote for going with just strict.

Completely agree. I'm against strict approach, but I would prefer
strict to strict+auto-conversion.

I see a sense in weak typehints. I see a lesser sense in strict. And I
see lesser lesser sense in combining the two.

And, for the record: I vote for keeping the status quo regarding
typehints. If this feature causes so much debate, why not leave it
until better times and concentrate on other ones?

I hope this comment will be of interest in the context of What would
be interesting to see is what people think of Derick's latest proposal
allowing both the strict typechecking and the more sensible weak
typing. I am a PHP end-user so I am one of the people, too.

2010/8/12 Zeev Suraski z...@zend.com:
 At 04:02 12/08/2010, Josh Davis wrote:

 What would be interesting to see is what people think of Derick's
 latest proposal allowing both the strict typechecking and the more
 sensible weak typing

 There's nothing new about it, it's been on the table for around half a year
 now.  Everyone who opposes strict typing on grounds that it's an alien
 feature to PHP(*) doesn't see any advantages in this suggestion, as
 everything that's bad in strict typing remains on the table.  If there were
 only two options left on earth, strict typing and strict+auto-conversion,
 I'd vote for going with just strict.

 Zeev

 (*)
 http://wiki.php.net/rfc/typecheckingstrictandweakhttp://wiki.php.net/rfc/typecheckingstrictandweak
 - 'Why is strict type checking problematic'



 --
 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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Victor Bolshov]

+1. Strict typing will only prevent PHP from being itself, while not
providing the advantages of a real statically types language (as Stas
Malyshev has mentioned in another thread of discussion).

2010/8/11 Arvids Godjuks arvids.godj...@gmail.com:
 Completly agree with Zeev, most russian comunity is for the weak type
 hinting. Many would like strict, but most of the pro strict type
 hinters understand that PHP and strict type hinting not match and vote
 for type hints with auto converting.

 --
 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

Re: [PHP-DEV] Strict typing (was: Typehints)

[Victor Bolshov]

Having two similar syntaxes that work differently - would make the
situation even worse that it is now - I beleive. And I totally agree
with Rasmus - strict typed language mustnt be called PHP. (Just a poor
user's notice to all of you internals' geeks out there)

2010/8/11 Stas Malyshev smalys...@sugarcrm.com:
 Hi!

 1. right now we *have* strict type checks for classes and arrays in the
    form of classname or array

 Because classes and arrays were never intechangeable types and there was
 never implicit or explicit conversion between SplRecursiveTreeIterator and
 Zend_Pdf_Generator - it doesn't even make sense to suggest it. There always
 was conversion between int and string or int and bool. These two things are
 completely different.

 2. the strict scalary type hint patch reuses this same syntax in the
    form oftype-name  to do the same thing in function arguments

 It's not a good thing. As I mentioned, primitive types and classes are very
 different in their use cases and established patterns in PHP. Primitive
 types are largely interchangeable, classes are not. (As for arrays, arrays
 really should be a class by their usage patterns etc. but for historic
 reasons... you know)

 3. we have casting type hints in the rest of the code in the form of
    (int).

 Just to make it simpler and less confusing, of course. It's nothing like
 language having two features that look almost exactly the same but work in
 different way, and using plenty of ()s is an added bonus for all Lisp fans
 out there.

 Some people don't like strict typehints, but the syntax as it currently
 is regarding type hints is *consistent*. Now, to allow both strict and
 casting hints, the logical step seems to be, to give the weak typehint
 advocates their tool as well:

 Calling something that works completely differently from all the established
 patterns of PHP - like internal functions, etc. - *consistent* requires
 totally new definition of this word.
 --
 Stanislav Malyshev, Software Architect
 SugarCRM: http://www.sugarcrm.com/
 (408)454-6900 ext. 227

 --
 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

Re: [PHP-DEV] Confusing performance of the magic method __call

[Victor Bolshov]

Shijiang, did you notice the

--
Warning: The magic method __call() must have public visibility and cannot be
static in Command line code on line 1
--

???

2010/8/3 Shijiang shiji...@staff.sina.com.cn

 Hi,

 In the following sample code, I expected that the magic method __call only
 works within the class Test.
 But it seems that the access control keyword private lost its efficacy when
 working together with the magic method __call.

 ?php
 class Test{
private function __call($name,$params){
echo $name,\n;
echo $params[0];
}

public function bar(){
$this-kakaka('afaafaf');
}
 }
 $foo=new Test;
 $foo-bar('sfsfss');
 $foo-nothing('works'); // this also works without any errors.
 ?

 IMHO, since the function __call is a method of a class, it should obey the
 visibility rules.

 Cheers.




-- 
С уважением,
Виктор

Re: [PHP-DEV] Confusing performance of the magic method __call

[Victor Bolshov]

Yes, sorry. I've been working with 5.3 for pretty long time so I found the
original letter a bit strange.

2010/8/3 Ferenc Kovacs i...@tyrael.hu

 2010/8/3 Victor Bolshov crocodil...@gmail.com:
  Shijiang, did you notice the
 
  --
  Warning: The magic method __call() must have public visibility and cannot
 be
  static in Command line code on line 1
  --
 
  ???
 
  2010/8/3 Shijiang shiji...@staff.sina.com.cn
 
  Hi,
 
  In the following sample code, I expected that the magic method __call
 only
  works within the class Test.
  But it seems that the access control keyword private lost its efficacy
 when
  working together with the magic method __call.
 
  ?php
  class Test{
 private function __call($name,$params){
 echo $name,\n;
 echo $params[0];
 }
 
 public function bar(){
 $this-kakaka('afaafaf');
 }
  }
  $foo=new Test;
  $foo-bar('sfsfss');
  $foo-nothing('works'); // this also works without any errors.
  ?
 
  IMHO, since the function __call is a method of a class, it should obey
 the
  visibility rules.
 
  Cheers.
 
 
 
 
  --
  С уважением,
  Виктор
 

 It was added/changed with 5.3 so it is not necessarly obvious.

 Tyrael




-- 
С уважением,
Виктор

Re: [PHP-DEV] [RFC] Return type-hint

[Victor Bolshov]

+1 for one could use the full qualified name to refer to the class name.

Making the developer care about the case of characters in one special case -
that's the sort of changes that lead to chaos. Remember that type conversion
works in a case-insensitive manner and so does most of the language
constructs:

(int) $x === (INT) $x
intvav($x) === INTVAL($x)
and so on

2010/7/29 Josh Davis php...@gmail.com

 On 29 July 2010 13:57, Felipe Pena felipe...@gmail.com wrote:
  My suggestion (I guess already told it in some mail...) is to
  identify the native php type just when it's lowercased (case-sensitive).

 Alternatively, one could use the full qualified name to refer to the
 class name, e.g.

 function expectsScalar(string $str) {}
 function expectsObject(\string $obj) {}

 -JD

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
С уважением,
Виктор

Re: [PHP-DEV] Type hinting

[Victor Bolshov]

As man from userland, I totally agree with Larry. I see completely no sense
in raising error when a safe conversion can be done. And I don't like
current implementation at all. It is completely not-php-way.

2010/5/28 Larry Garfield la...@garfieldtech.com

 On Friday 28 May 2010 01:54:55 am Zeev Suraski wrote:
  At 08:28 28/05/2010, Tjerk Anne Meesters wrote:
  On the other hand, auto-casting used to be my favourite until I
  glanced over the conversion table; it's not just regular casting, it
  has different rules. I wouldn't want to be the one going over that
  table when writing code against a certain API, I should only need to
  see the documentation.
 
  Tjerk,
 
  I think you have a nice idea about E_STRICT, except it makes much
  more sense with auto-conversion.  That is - in case of 'fail' - we'd
  still convert, and emit E_STRICT (or E_NOTICE).  That means that the
  API developer will always get the type he expects, while the user
  will be guided in the right direction in a friendly PHPish manner.
  The conversion table is up for discussion, BTW.  If most people
  prefer that it's more similar to PHP's existing auto-conversion rules
  (that appears to be the case) we can certainly do that.
 
  Zeev

 I'm not 100% sure I follow, Zeev.  Are you suggesting:

 foo (int $a) { }

 foo(1); // Works, no message
 foo(1); // Works, no message
 foo(1a); // Emits E_STRICT or E_NOTICE and casts to a 1
 foo(array(1)); // Fatal

 I could get behind that.  In fact it also suggests that we could (later?)
 alter the normal casting rules so that if you do a lossy conversion you get
 a
 notice/strict in any case.  Something to chew on.

 I like that idea, as the purely strict typing that's in HEAD right now I
 find
 worse than having no scalar type checking at all.

 --Larry Garfield

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
С уважением,
Виктор

Re: [PHP-DEV] Type hinting

[Victor Bolshov]

+1 vote for weak typing.

I myself often (but not always) do take care about types, so for me
personally strict typing won't hurt that much. However, I beleive this will
be an overcomplicated aspect to many. As we know, there are tons of
webmasters who dont know any programming language in deep - but need to
write code and use libraries from time to time. And, after all, PHP had
always made things simple, not hard.

And a few more words about libraries. When using PHP-API for the Sphinx
search engine, you often see warnings regarding argument types. That's
because the author had put assert()s in every function that check argument
types. You have to settype(), although you know for sure that, say, a
category ID that you get from a database, can be safely converted to int.
While being defensive, this style is at least strange for a php-man.

2010/5/27 Arvids Godjuks arvids.godj...@gmail.com

 I have posted a topic on main Russian site for IT. Soon we will have a
 result on what the Russian community thinks on this matter.

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php




-- 
С уважением,
Виктор

Re: [PHP-DEV] Proposal: shorthand object property setting syntax.

[Victor Bolshov]

Toorion, I suggest *not* your code becomes unreadable because of PHP
limitations but because of you application architecture limitations.

I see from your example that you're building a Ext.JS datagrid. And,
what is done in the example, is writing in PHP what should be written
in JavaScript. ExtJS requires much code to be written, but when you
write it in JS - it is more convenient to than in PHP: in JS you have
shorthand syntax for objects ( x = { y: z }; ), shorthand syntax for
arrays ( x = [y, z] ). When creating a Ext.Datagrid in Javascript,
I have never seen constructs like  grid.store.reader.fields[++i] = .
To my mind, when you need a PHP backend for a Javascript-datagrid, the
only thing you need in PHP - is a possibility to answer to the
datagrid HTTP-queries in a way that a grid can understand.

And, regarding this:

 Much better if we can join attributes directly from object initialization.
 $instance = new ObectName() { $attr1 = 'value', $attr2 = 'value' );
 That we can set any value of object and don't needed to make decision which 
 of attributes is important and which not.

I dont know much of PHP internal structure but I can see a conflict in
this syntax: what if in a user-defined __construct() method, there
already is an assignment for $this-attr1 and $this-attr2 ?

Example: class ObectName { function __construct() { $this-attr1 = 'a
result of complex calculations'; } }

What value should attr1 be assigned after we've done $instance = new
ObectName() { $attr1 = 'value', $attr2 = 'value' ); ? Should an error
be raised? What about access modifiers? Should there be a possibility
to access private/protected properties with the new syntax? (If so, it
would certainly break encapsulation and introduce mess).

In the end, I could only mention that the above does not have a
relation to named parameters (Stan Vassilev talks about them in the
further discussion). Personally, I think, named parameters might be a
useful addition to the language.

2010/3/27 Toorion toor...@gmail.com:
 On 03/27/2010 07:23 PM, Martin Jansen wrote:

 On 27.03.10 17:02, Toorion wrote:

 $myLongNameObject = new MyLongNameObject();
 $myLongNameObject-property1 = '1';
 $myLongNameObject-property2 = '2';
 $myLongNameObject-property3 = '3';
 $myLongNameObject-property4 = '4';
 $myLongNameObject-property5 = '5';

 [...]

 $MyLongNameObject = new MyLongNameObject() {
     $property1 = '';
     $property2 = '';
     $property3 = '';
     $property4 = '';
 }

 What exactly do you gain with the new syntax?

 Readable code. Simplicity of developing, debugging.
 So, I write short example. Actually I work with long UI code (DOM, PHP-ExtJS
 implementation, more other new UI solution) and that code look like this:

 $grid = new ExtGridPanel();
 $grid-store = new JsonStore();
 $grid-store-autodestroy = true;
 $grid-store-url = 'plain.xml';
 $grid-store-reader = new JesonReader();
 $grid-store-reader-record = 'plant';
 $grid-store-reader-fields = array();
 $i = 0;
 $grid-store-reader-fields[$i] = new StoreField();
 $grid-store-reader-fields[$i]-name = 'common';
 $grid-store-reader-fields[$i]-type = 'string';
 $grid-store-reader-fields[++$i] = new StoreField();
 $grid-store-reader-fields[$i]-name = 'botanical';
 $grid-store-reader-fields[$i]-type = 'string';
 $grid-store-reader-fields[++$i] = new StoreField();
 $grid-store-reader-fields[$i]-name = 'light';
 $grid-store-reader-fields[++$i] = new StoreField();
 $grid-store-reader-fields[$i]-name = 'price';
 $grid-store-reader-fields[$i]-type = 'float';
 $grid-store-reader-fields[++$i] = new StoreField();
 $grid-store-reader-fields[$i]-name = 'availDate';
 $grid-store-reader-fields[$i]-type = 'date';
 $grid-store-reader-fields[$i]-mapping = 'availability';
 $grid-store-reader-fields[$i]-dateFormat = 'm/d/Y';
 $grid-store-reader-sortinfo = new stdClass();
 $grid-store-reader-sortinfo-field = 'common';
 $grid-store-reader-sortinfo-direction = 'ASC';
 $grid-renderTo = 'editor-grid',
 $grid-width = 600;
 $grid-height = 300;
 $grid-autoExpandColumn = 'common';
 $grid-title = 'Edit plants';
 $grid-frame = true;
 $grid-tbar = new ExtTBar();
  more code with setting of tbar properties
 $grid-items = array();
 $i = 0;
 $grid-items[$i] = new GridItem();
 $grid-items[$i]-id = 'common';
 $grid-items[$i]-header = 'Common name';
 $grid-items[$i]-dataIndex = 'common';
 $grid-items[$i]-width = 220;
 $grid-items[$i]-editor = new GridColumnEditor();
 ... more properties of GridColumnEditor 
 ... more properties of next few items 

 So, as you can see, this code (small part of PHP-ExtJS UI implementation)
 absolute unreadable. Yes, I can use variables like this:

 $r = new JsonReader();
 $r-record = 'plant';
 $r-fields = array();
 $i = 0;
 $r-fields[$i] = new StoreField();
 $r-fields[$i]-name = 'common';
 $r-fields[$i]-type = 'string';
 $r-fields[++$i] = new StoreField();
 $r-fields[$i]-name = 'botanical';
 $r-fields[$i]-type = 'string';

 And:

 

Re: [PHP-DEV] Scary note for gettype() in docs

[Victor Bolshov]

From the user point of view it might seem that 5.x string and 6.x
unicode are all strings, whatever you call them. Still, I am sure
there _is_ a background for the decision to distinguish between
string and unicode.

2 марта 2010 г. 1:27 пользователь Antony Dovgal t...@daylessday.org написал:
 On 03/01/2010 11:35 PM, Stan Vassilev wrote:

 Hi,

 The gettype() documentation warns people that the returned string is 
 subject to change.
 Why is there a function that's subject to change in the API?

 Because life is complicated.
 Because gettype(test) returns string in 5.x and unicode in 6.0.

 What exactly are you trying to fix? And what exactly are you proposing?

 --
 Wbr,
 Antony Dovgal
 ---
 http://pinba.org - realtime statistics for PHP

 --
 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

Re: [PHP-DEV] Dots and spaces in variable names are converted to underscores.

[Victor Bolshov]

 And I'm not sure who would actually use 'a.b' and then expect 'a_b',
 but I have to assume somebody has done that, perhaps consuming an API
 from somewhere else.

OpedID protocol uses dots in query string arguments. The
implementations could be broken by the patch.

While the keep arguments as is behaviour is certainly better in the
long run - issues like OpenID should be taken into account.

2010/1/21 jvlad d...@yandex.ru:

 For BC, I suppose PHP could have *both* 'a.b' and 'a_b', or yet
 another php.ini flag (sorry!) to choose the behaviour.

-1 from me.
I don't think we need to keep backward compatibility for this. PHP-6 is a
major release, after all.

It would be absolutely enough to add optional var-name conversion to
extract()=

 By default extract _ignores_ variables with dots like a.b
 Even though register_globals should be removed, it does not mean that the
 default behaviour of extract
 should be changed.
 If it's _necessary_ to provide a way to mimic register_globals
 functionality, a special flag for it should
 be added, something like EXTR_MIMIC_REGISTER_GLOBALS that will replaces
 incorrect characters
 in the variable names with underscrores.
 In this case BC won't be broken.



 --
 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

Re: [PHP-DEV] Closures and $this: Please vote!

[Victor Bolshov]

I vote for (A). bind() and bindTo() seem messy to me. However, I
mostly vote for no implicit $this changes in closures (no
javascript-like behaviour), so (A+) approach would be much better than
(C) or (D). (0) case is not my choice, because I really would like to
see $this support in closures back.

Regards,
Victor

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Closures and $this

[Victor Bolshov]

Hi

 so you can with $foo-$bar() or $foo()

You're talking about variable functions/methods. But that is not the
subject of discussion. Variable functions/methods are useful but
introduce mess. This is well-known and this feature exists in PHP for
a long time - so everybody should be condidered as warned - when they
use it.

I am talking about $this-methodName() constructions. Currently, in
PHP, one can be pretty sure that if this construction works in one
place - it should work in another (I mean, methodName() will exist in
$this). To be mentioned - I'm not using variable functions here.

2009/11/19 Stanislav Malyshev s...@zend.com:
 Hi!

 If php-people really would like rebinding $this, I beleive this should
 be done via method like Closure-bindTo() - to make the fact of
 rebinding clear in the code.

 However, there is a problem with rebinding $this - that was not
 mentioned yet, I think.

 This can be a problem, but since PHP is not a compiled language, this
 problem already exists - all method names are only checked in runtime
 anyway, so it doesn't matter if you rebind the closure or not. Of course,
 with rebinding you can easily shoot yourself in the foot by calling
 non-existing method - but so you can with $foo-$bar() or $foo() or a number
 of other ways. So I think if this construct is expressed in a way that makes
 the intent clear (i.e., no implicit rebinding) then it would be OK.
 --
 Stanislav Malyshev, Zend Software Architect
 s...@zend.com   http://www.zend.com/
 (408)253-8829   MSN: s...@zend.com




-- 
Regards,
Victor

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Closures and $this

[Victor Bolshov]

Hi.

Personally, I beleive that (A) approach is the best: bind $this to
the object scope at creation and never change it, issue error when
$this is used where not available. It also seems to me like this way
it could be implemented with better performance, am I right?

Dynamically changing $this introduces confusion. You can use
$this-foo or $this-bar() inside a closure, but when $this
dynamically changes - you cannot be sure that foo property or bar
method is still there. Furthermore, dynamic approach introduces even
more mess when thinking about availability of private/protected class
members.

Consider this code:

class Foo {
  private $closure;
  function __construct()
  {
/* It seems natural to me that, doing this assignment from within the class,
   one can use private members inside the closure */
$this-closure = function() { $this-privateMethod(); };
  }
  function setClosure($closure)
  {
$this-closure = $closure;
  }
  function getClosure()
  {
return $this-closure;
  }
}

$foo = new Foo();
$foo-getClosure()-__invoke();// #CALL-1
$foo-setClosure(function() {
  /*
  But is it good to use private members here? It seems like it would
break encapsulation,
  and the information that the class was designed to hide - is now
made available in public access,
  although indirect.
  */
  $this-privateMethod();
});
$foo-getClosure()-__invoke();// #CALL-2

In the end, I would like PHP to issue error when $this is used in
#CALL-2 but to continue working on #CALL-1.

The (A) approach seems to me more predictable, more simple, it has
less information the developer needs to keep in mind when using
closures.

2009/11/17 Mathieu Suen mathieu.s...@easyflirt.com:
 Chris Stockton a écrit :

 Hello,

 On Tue, Nov 17, 2009 at 2:59 AM, Mathieu Suen
 mathieu.s...@easyflirt.com wrote:

 Christian Seiler a écrit :

 Hi,

 since a few months have passed since the last discussion on this topic
 and perhaps people had time to gather some experience with the current
 closure implementation in PHP 5.3 I'd like to restart the debate on
 $this in closures and object extension.

 I believe that (D) wins my vote, and it convinces me twice. Once
 because I believe it is the most intuitive for users (A), and twice
 because I believe it is also the most useful (C) for users. In my
 opinion It seems the most PHP way.

 -Chris


 (D) is quite inconstant:

 $block = $foo-closur;

 $foo-closur();
 $block();

 This would produce 2 different output.
 For (C) here is my objection:

 Suppose that we are in a MVC pattern.
 In a controller on could do:

 $model-onFailDo(function () {$this-reportError()});
 $model-save();


 In the model side:

 public function onFailDo($block)
 {
        $this-signalFailure = $block
 }

 public function save()
 {
        //... Something wrong happen
        return $this-signalFailure();
 }

 If you dynamically bind the $this you are obliged to treat the error
 reporting in the model which is not a good idea. Even worst you can't even
 catch up the error in the controller.
 It also mean that the closure is getting tightly coupled with anyone who is
 using it. And passing closure to different object is like spreading
 dependency over all the system.

 -- Mathieu Suen

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php



-- 
Regards,
Victor

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] bug when using foreach with references?

[Victor Bolshov]

That's a completely useless discussion, isn't it? Whoever is right
with his opinion regarding scoping - nobody will (and nobody would
like to) change PHP's scoping for those reasons as it would break too
much existing code.

2009/11/16 Mathieu Suen mathieu.s...@easyflirt.com:
 Etienne Kneuss a écrit :

 Hello,

 On Mon, Nov 16, 2009 at 2:10 PM, Mathieu Suen
 mathieu.s...@easyflirt.comwrote:

 Pierre Joye a écrit :

  On Mon, Nov 16, 2009 at 12:07 PM, Mathieu Suen

 mathieu.s...@easyflirt.com wrote:

  • Pensez à l'environnement, n'imprimez cet e-mail qu'en cas de réelle

 nécessité

 Discussing endlessly an issue only because you do not understand it is
 also an environmental problem, please consider to read the manual and
 stop to use every single channel to ask the same questions again and
 again.

 Salutations,

 That's not a question, look at what lisp dose and scheme.
 Look at the lambda calculus etc.

 The variable inside the foreach should not be captured outside.
 Like function argument. And again and again you are doing the same
 mistake:


 Static scoping is closely related to variable declaration. In PHP, there
 is
 no such thing as a variable declaration statement (apart from function
 arguments or class members, which are correcly scoped).

 I am pretty sure you can have static scoping without declaration statement.
 Or you can consider $a = 2 as a declaration statement.
 Which imply that

 if (..) { $a = 2; } else { $a = 3; }

 Produce 2 bindings of $a or can be a free if you 'declare' it outside .
  As:

 $a = null;
 if (..) { $a = 2; } else { $a = 3; }

 What's strange is that part of the language is statically scoped will the
 other part is dynamic.
 See function vs. if, loop statement.

 Even worst if you think of the $_GET variable which should have a special
 scope...

 There is only an

 assign statement, that may introduce a new variable, or not. Without such
 a
 declaration statement, static scoping doesn't make much sense.

 For example:

 if (..) { $a = 2; } else { $a = 3; }

 echo $a;

 would either fail or require some branch analysis at compile time to work.
 which we can't really afford.

 Or:

 $a = 2;

 if (...) { $a = 3; }

 There is no way of stating whether $a = 3; should be for a $a that is
 unrelated to the outer $a.


 In other words, the kind of scoping you want will most likely never be
 implemented in PHP.

 Best


 Dynamic scoping is primarily interesting as a historical mistake: it was
 in the earliest versions of Lisp,
 and persisted for well over a decade. Scheme was created as an
 experimental
 language in part to experiment
 with static scope. This was such a good idea that eventually, even Common
 Lisp adopted static scope.
 Most modern languages are statically scoped, but sometimes they make the
 mistake of recapitulating this
 phylogeny. So-called “scripting” languages, in particular, often make the
 mistake of implementing dynamic
 scope (or the lesser mistake of just failing to create closures), and
 must
 go through multiple iterations before
 they eventually implement static scope correctly.
 - Shriram Krishnamurthi, Programming Languages:
 Application and Interpretation section 6.5:

 -- Mathieu Suen



 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php






 -- Mathieu Suen

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php



-- 
Regards,
Victor

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] Request for Comments: Horizontal Reuse for PHP

[Victor Bolshov]

Personally, I don't get deep into how PHP works inside, I'm just a
PHP-programmer (the man from userland). For me it will surely be
better to use 'insteadof', not 'instead'. And It seems to me more
natural to use the following syntax when using grafts:

class Foo {
 use MyGraft {
  public graftedClassMethodBar() as bar();
 }
}

$foo = new Foo();
$foo-bar();

2009/10/15 Tom Boutell t...@punkave.com:
 I'm very concerned about the practical consequences of introducing
 traits without state.

 Lacking support for properties (state) in traits, programmers will
 immediately start hacking properties in anyway.

 I see two approaches:

 A. They could do this using static hashes in global variables or a
 separate class. The result is a garbage collection failure as these
 references to $this will never go away. Designed-in GC failures are
 unacceptable post PHP 5.3.

 B. PHP allows you to define properties at runtime. That is, you can write:

 $this-title = 'my title';

 Without declaring var $title; at the class level.

 But PHP 6 seems to be moving toward more strictness, not less, and
 this style encourages the use of undeclared variables with the
 resulting potential for missed bugs.

 * * *

 Also, the 'instead' keyword is baffling - it could mean replace A with
 B or replace B with A depending on how you place your mental comma - I
 much prefer the assignment syntax alternative, or 'insteadof' which is
 unambiguous.

 On Wed, Oct 14, 2009 at 4:07 PM, Lukas Kahwe Smith m...@pooteeweet.org 
 wrote:

 On 14.10.2009, at 22:03, Stanislav Malyshev wrote:

 Hi!

 So lets warm this up again.
 HEAD is for development .. so lets get this into HEAD so that it will be
 part of the next bigger PHP release for sure!

 Well, the code is sitting here
 http://github.com/gron/php-src/tree/PHP_6-traits
 and waits to be merged. :)

 I thought before merging code it would be useful to have some discussion
 on if the code is actually doing what we want. If it's based on
 http://wiki.php.net/rfc/horizontalreuse then for example I can see some
 potential issues for bytecode caching related to renaming and changing
 visibility.
 Also, it is not clear that we want grafts there at all, some aspects of
 them seem to get too hairy, esp. $this issue or statics.


 i think Stefan is fully aware of that probably there will be a discussion
 first ..
 but i think we all agree that this feature is very high on the list of what
 people want and therefore i wanted to get this discussion going, so that
 after its concluded traits can be commited to HEAD.

 regards,
 Lukas Kahwe Smith
 m...@pooteeweet.org




 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





 --
 Tom Boutell
 P'unk Avenue
 215 755 1330
 punkave.com
 window.punkave.com

 --
 PHP Internals - PHP Runtime Development Mailing List
 To unsubscribe, visit: http://www.php.net/unsub.php





-- 
Regards,
Victor

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php