Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi! I agree with you. The one case where this syntax may be very useful is if we want to implement class casting. So introduce a pair of magic methods I do not think we want to implement class casting. I'm not sure how class casting even makes sense - if the object is of one class, how can you just make it into another class by casting? If you mean casting actually returns another object of different class, then just make a method for that that returns that object, I do not see how obscuring the purpose of this operation with unobvious syntax would help. The discussion is starting to drift very far from my original proposal. Instead of trying to guess what I mean, can't people just refer to my very simple definitive proposed behavior? My proposal is simple: behave as an inline type hint. The same type hints you have in arguments lists, but inline. The use case is I want to make sure this value is of this type and a side benefit is the IDE can know the variable is of this type too (for autocompletion purposes). Whether they'd be exposed with the cast syntax or otherwise isn't that important. Languages like ActionScript expose inline type validation both by static typing hints and by casting. In both cases the operation simply validates the class can be seens as an instance of this class/interface. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi!
My proposal is simple: behave as an inline type hint. The same type hints
you have in arguments lists, but inline. The use case is I want to make
sure this value is of this type and a side benefit is the IDE can know the
variable is of this type too (for autocompletion purposes).
What's wrong with instanceof? You can then throw fatal error if you
want, it's just two lines:
if(!($foo instanceof Bar)) {
trigger_error(E_USER_ERROR, Wrong foo!);
}
--
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
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
I'd like to also ask people to read what the intended effect of the proposal
is instead of going into abstract discussions about how casting one class to
another doesn't make sense (this is not what's being proposed).
Just like PHP typehints look like static typing but *aren't*, the same way
the fact this looks like a static cast *doesn't* make it so. A dynamic
language can't have static casts, and I'd think this is obvious to
everybody.
Instead, I'm adapting the principle so it fits with existing PHP behaviors
and patterns.
Syntax which looks like static typing is fine by me as well. Examples:
ClassName $foo = expression();
foreach ($list as InterfaceName $item) { ... }
etc.
The only operation done here is validating the variable is a valid instance
of this type. No transformation is happening.
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
What's wrong with instanceof? You can then throw fatal error if you
want, it's just two lines:
if(!($foo instanceof Bar)) {
trigger_error(E_USER_ERROR, Wrong foo!);
}
That's 3 lines on top of the line where you assign the value, and you forgot
the 4th line for the IDE:
-
/* @var $foo Bar */
$foo = expression();
if(!($foo instanceof Bar)) {
trigger_error(E_USER_ERROR, Wrong foo!);
}
-
Versus this:
Bar $foo = expression();
And assignment is a kinda common operation. So I hope you can see what's
wrong with it now.
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi! And assignment is a kinda common operation. So I hope you can see what's wrong with it now. No I do not. Not every imaginable use case should have dedicated language construct for it - sometimes it is OK to type 2 lines of code. Sometimes even 3. This case is well served by existing language syntax, which also allows much more flexibility and control over what happens if the variable does not match. I see no reason to invent language construct the only purpose of which is to save you typing one if clause. -- 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
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
And assignment is a kinda common operation. So I hope you can see what's wrong with it now. No I do not. Not every imaginable use case should have dedicated language construct for it - sometimes it is OK to type 2 lines of code. Sometimes even 3. This case is well served by existing language syntax, which also allows much more flexibility and control over what happens if the variable does not match. I see no reason to invent language construct the only purpose of which is to save you typing one if clause. Let me ask you - do you think the existing PHP typehints are pointless too? Do you feel they don't give you enough flexibility? Do you feel they reinvented a language construct for the purpose of saving the typing of one if clause (per argument) (per method) (per class)? And why do you keep ignoring the fact that IDE's need additional clutches to understand the type of the variable? Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
On Wed, Aug 15, 2012 at 10:06 AM, Stan Vass sv_for...@fmethod.com wrote: I'd like to also ask people to read what the intended effect of the proposal is instead of going into abstract discussions about how casting one class to another doesn't make sense (this is not what's being proposed). I think you confused everyone by a) having typecasting in the title and b) starting with the (Foo) casting syntax (so everyone assumed that you indeed want some kind of class casts, whatever that may be). Regarding the actual proposal, could you maybe clarify the use-cases for this? I can see that it could be useful in principle, but your actually named use cases confuse me somewhat. In particular, I don't see how this would help dependency injection containers. I can see that it helps service locators and registries, but both of those are considered antipatterns, so there is no reason to add additional language features for them. DICs are only used to inject top-level dependencies, so in that case types should be fairly well covered by parameter type hints. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi! Let me ask you - do you think the existing PHP typehints are pointless too? Do you feel they don't give you enough flexibility? Do you feel they reinvented a language construct for the purpose of saving the typing of one if clause (per argument) (per method) (per class)? They are not pointless, but I think they are often misunderstood and not used correctly. And they definitely lack flexibility in many cases. But they are helpful for one important thing - defining interface between the method and the method client. Having strictly typed variables does not serve it, and trying to make PHP into half-baked half-statically-typed language does not sound like a good idea to me. And why do you keep ignoring the fact that IDE's need additional clutches to understand the type of the variable? Because I don't think inventing language constructs for the purpose of helping IDEs simulate static typing in dynamically typed language makes much sense. -- 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
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
On Wed, Aug 15, 2012 at 10:06 AM, Stan Vass sv_for...@fmethod.com wrote:
I'd like to also ask people to read what the intended effect of the
proposal
is instead of going into abstract discussions about how casting one class
to
another doesn't make sense (this is not what's being proposed).
I think you confused everyone by a) having typecasting in the title
and b) starting with the (Foo) casting syntax (so everyone assumed
that you indeed want some kind of class casts, whatever that may be).
I had typecasting / typehinting in the title, and I'd like to remind
everyone again that in dynamically typed languages class casts are often
implemented as a basic validation operation, consistent with what I
proposed.
Regarding the actual proposal, could you maybe clarify the use-cases
for this? I can see that it could be useful in principle, but your
actually named use cases confuse me somewhat. In particular, I don't
see how this would help dependency injection containers. I can see
that it helps service locators and registries, but both of those are
considered antipatterns, so there is no reason to add additional
language features for them. DICs are only used to inject top-level
dependencies, so in that case types should be fairly well covered by
parameter type hints.
Two use cases apart from registries: PHP has no typed iteration and arrays,
so you the only way to guarantee (and the IDE to know) the type of a
variable in these cases is a hint:
Foo $bar = $array[1];
foreach ($array as Foo $item) { ... }
Automatically this applies to everything that uses ArrayAccess as a
shorthand too, and properties of anonymous objects (stdClass).
The current alternative is peppering code with pseudo-PHPDoc inline hints,
and instanceof assertions which truly is a facility the language core should
provide, instead of us emulating it.
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi!
Let me ask you - do you think the existing PHP typehints are pointless
too?
Do you feel they don't give you enough flexibility? Do you feel they
reinvented a language construct for the purpose of saving the typing of
one
if clause (per argument) (per method) (per class)?
They are not pointless, but I think they are often misunderstood and not
used correctly. And they definitely lack flexibility in many cases. But
they are helpful for one important thing - defining interface between
the method and the method client. Having strictly typed variables does
not serve it, and trying to make PHP into half-baked
half-statically-typed language does not sound like a good idea to me.
All right, your method accepts an array of objects, instances of Foo. How do
you enforce this contract?
Here's how my proposal enforces it:
function foobar(array $collectionOfFoo) {
foreach ($collectionOfFoo as Foo $item) {
...
}
}
What's your proposal? From the discussion so far, I'd guess it's peppering
out code with if-s with the same error written everywhere everytime we check
the item in an array.
Because I don't think inventing language constructs for the purpose of
helping IDEs simulate static typing in dynamically typed language makes
much sense.
The same applies to typehints, so make up your mind.
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi! All right, your method accepts an array of objects, instances of Foo. How do you enforce this contract? You are trying to re-invent generics/parametrized types and bolt it onto PHP. I still don't think it is a good idea - PHP is not a statically typed language. Just check you array elements if you need. What's your proposal? From the discussion so far, I'd guess it's peppering out code with if-s with the same error written everywhere everytime we check the item in an array. By peppering here you mean one if. Yes, this is my proposal - if you need to do a check - do a check. The same applies to typehints, so make up your mind. No it does not. But this is exactly why I think one of the problems with strict typing in arguments is - because people take it and starting to use it as a legitimation of turning PHP into weird hybrid of dynamically typed language with random islands of static typing popping in random places. I still do not think it is a good idea. -- 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
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Hi! All right, your method accepts an array of objects, instances of Foo. How do you enforce this contract? You are trying to re-invent generics/parametrized types and bolt it onto PHP. I still don't think it is a good idea - PHP is not a statically typed language. Just check you array elements if you need. You're 10 years too late to argue the merits of typehints in PHP. I am not proposing the introduction of typehints. I'm just saying we have the option to use them in arguments, let's have the options inline too. This way we can validate expressions and structures we can't today, in a minimal, readable, consistent, easy to maintain way. By peppering here you mean one if. Yes, this is my proposal - if you need to do a check - do a check. Yes, exactly: one if. For your entire codebase that has one single assignment in it. Or one foreach. Pick one or the other, but not both, otherwise they become two ifs, and that invalidated your argument. The same applies to typehints, so make up your mind. No it does not. But this is exactly why I think one of the problems with strict typing in arguments is - because people take it and starting to use it as a legitimation of turning PHP into weird hybrid of dynamically typed language with random islands of static typing popping in random places. I still do not think it is a good idea. Saying weird hybrid random islands popping random doesn't make simple type validation hints any more awkward than they were yesterday before I posted this thread, Stas. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
On Wed, Aug 15, 2012 at 11:17 AM, Stan Vass sv_for...@fmethod.com wrote: You're 10 years too late to argue the merits of typehints in PHP. I am not proposing the introduction of typehints. I'm just saying we have the option to use them in arguments, let's have the options inline too. This way we can validate expressions and structures we can't today, in a minimal, readable, consistent, easy to maintain way. Stas already pointed out that parameter typehints allow you to define the interface for your method. Return typehints would server a similar purpose and as such I'd consider them useful. But variable typehints don't serve any such purpose. Actually, one could even say that they don't serve *any* purpose, short of providing the IDE with type information, because your code would work just as well even without the type check. If the type were wrong, it would just throw a fatal error when trying to do something with it (like invoking a method that does not exist). And if the sole purpose is type hinting for the IDE, then I don't see what's wrong with the established system of PHPDoc comments. They seem to serve the same purpose, don't they? Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] php_basic ...
I am trying to follow all the latest threads on various decorators, casting, contracts, iterators, interfaces and the rest but I have to be honest ... I simply don't understand the majority of what is being discussed. All right I don't have to use it, but on the whole I have no problem with any of the existing code. Except perhaps for zend, but that is mainly because I just don't work the way it is trying to force me. I can quite happily work on existing third party libraries, debug and fix problems, and move forward. But the examples being given simply don't fit with my view of how PHP works. How much of this taint/reflection/... is actually going to be used by the majority of users? I keep seeing references to 'compile time' and thinking when on earth does compiling come into the equation? When I process a page request I load just the components needed to do the job, and if something is wrong I give an error page. A hell of a lot of the comments being made relate to the IDE and THAT is where the bulk of this checking should be provided, not loading down the runtime engine with checks that should have been done when writing the code? I know I keep harping on about it, but it still seems to me that there is no cohesive basic framework defined for the core functionality needed to run simple php scripts? SOmething on to of which all the esoteric bits can be added and explained without having to dig through numerous RFC's and release notes to see what the current state of play is :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Stas already pointed out that parameter typehints allow you to define the interface for your method. Return typehints would server a similar purpose and as such I'd consider them useful. But variable typehints don't serve any such purpose. I gave an example validating an array of Foo instances, which the current system doesn't solve. Of course PHP could extend argument typehints to describe this, but Stas *just* said he doesn't want generics and so on in PHP. All right, I don't either. I just want a clean way to describe my expectation that a variable is what it is, and assuming that all function arguments are one single instance simply doesn't match the real world out there. People iterate arrays, they pass arrays around. And they have expectations for what's inside those arrays. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
But variable typehints don't serve any such purpose. Actually, one could even say that they don't serve *any* purpose, short of providing the IDE with type information, because your code would work just as well even without the type check. If the type were wrong, it would just throw a fatal error when trying to do something with it (like invoking a method that does not exist). Just like with argument typehints. Point me to an argument typehint that is required for your code to run. You and Stas keep giving arguments against argument typehints, which is really awkward. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
On Wed, Aug 15, 2012 at 12:01 PM, Stan Vass sv_for...@fmethod.com wrote: Just like with argument typehints. Point me to an argument typehint that is required for your code to run. You and Stas keep giving arguments against argument typehints, which is really awkward. As already pointed out repeatedly, argument typehints serve the purpose of defining an interface. No, they are not required to run the code, that's true. But they still serve an important purpose for object oriented programming (and, just to make sure that you don't miss it again: That purpose is defining the interface). Variable typehints do not, as far as I can see. I gave an example validating an array of Foo instances, which the current system doesn't solve. Yes, and your system doesn't solve it either, or does it? As the validation does not happen through a parameter typehint it does not help defining the public interface. It only helps the IDE know the type (which doc comments can also do). Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
On 15 August 2012 18:15, Nikita Popov nikita@gmail.com wrote: As already pointed out repeatedly, argument typehints serve the purpose of defining an interface. No, they are not required to run the code, that's true. But they still serve an important purpose for object oriented programming (and, just to make sure that you don't miss it again: That purpose is defining the interface). Variable typehints do not, as far as I can see. I was most of the way through writing a much longer e-mail responding to the original post, but you and Stas have summed it up well, really. Type hints actually have a use in the object model of PHP in terms of interface definition. The only uses I can see for these variable hints are: 1. An informative use for IDEs, as previously noted, which is already filled adequately by @var documentation. 2. An assertive use in development: effectively, a different way of writing assert($var instanceof ClassName) to verify your assumptions on variable types. Personally, I don't think either of those justify the addition of the feature. The thing is that even ignoring type hints' interface definition functionality and treating them as pure syntactic sugar, type hints have another benefit: if you have several parameters to a function, type hints allow you to verify their classes in one hit, rather than having to make several calls to a verification function or implement something like zpp for objects in userspace. That leads to neater, shorter code. This feature doesn't have that quality: you can only hint one variable at a time, so there's not even a significant saving in time/typing for the developer between (to pick the only version of the syntax I don't find completely objectionable) ClassName $var = $object; and $var = isType($object, 'ClassName');. In summary, I guess I'm -1 on the feature, and -10⁹ on any version of the feature that looks like a typecast. :) Adam -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Decorators Revisited
On 14 August 2012 at 20:58 Stas Malyshev smalys...@sugarcrm.com wrote: Hi! Simply because your object responds to all the same methods of, for example, the FooInterface, does not make it a FooInterface subtype. It just means that in the duck typing sense of the phrase, it can act like a FooInterface for people that are not necessarily concerned that it's actually not is_a() FooInterface. Excellent point here. I have a feeling that with these proposals people want to eat a cake and have it too. To have strictly defined typing structure enforced by strict parameter checks, instanceof checks, etc. and at the same time have the freedom of duck typing. I don't think it's going to work well - if you want duck typing, that's one thing, if you want class hierarchy, that's another thing. Both are viable models for different cases, but I don't see how they can work using the same operators and language constructs. They should be distinct. This is something which bothers me about PHP as it is at the moment. PHP seems to me like it should be a dynamic language, and it is quite dynamic: no static typing, has weak typing, you can add instance members at runtime, etc. However, there has been a trend for adding more... non-dynamic (?) features to the language. Interfaces for example. Yet you can also duck-type things. I think PHP risks becoming very unclear as to what the right way to do things is. It must be confusing to write code that has to deal with both duck-typing and interfaces. I just think perhaps PHP should decide if it's supposed to be dynamic or non-dynamic, because just now it looks like a confusing mix of both. (although I guess duck-typing can be used for interfaces, just not really the other way round, i.e. if you expect an object of an interface you can't just pass one implementing the required methods) Or, if it is going to support both models, it should at least have first-class support for both. Being able to dynamically modify classes, for instance. Now, we could probably make duck typing a bit easier by allowing to check if specific object can respond to specific interface. But I'm not sure if it's worth the effort - why not just have it implement the interface then? In any case, I think duck typing improvement may be a good place for proposals, but let's not confuse it with inheritance hierarchy. What if asking for an interface just checked to see if a class implemented the required types, and implements didn't make the class have that interface, but just made the compiler error if it didn't implement everything required. -- 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 -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php_basic ...
Hi, I know I shouldn't feed the troll, but I want to say this once and for all and be clear about it. On 15 August 2012 at 10:32 Lester Caine les...@lsces.co.uk wrote: I am trying to follow all the latest threads on various decorators, casting, contracts, iterators, interfaces and the rest but I have to be honest ... I simply don't understand the majority of what is being discussed. All right I don't have to use it, but on the whole I have no problem with any of the existing code. Except perhaps for zend, but that is mainly because I just don't work the way it is trying to force me. I can quite happily work on existing third party libraries, debug and fix problems, and move forward. But the examples being given simply don't fit with my view of how PHP works. How much of this taint/reflection/... is actually going to be used by the majority of users? I keep seeing references to 'compile time' and thinking when on earth does compiling come into the equation? When I process a page request I load just the components needed to do the job, and if something is wrong I give an error page. A hell of a lot of the comments being made relate to the IDE and THAT is where the bulk of this checking should be provided, not loading down the runtime engine with checks that should have been done when writing the code? The examples don't have to fit the way you think PHP works. PHP doesn't have to work the way you want, and it doesn't have to do only what you want. PHP should be a rich language, a language enabling someone to do all the wonderful things they need to do, not necessarily only what you want to do. Regarding checks and such, you know, PHP will be filled with checks in the runtime anyway because you need to parse and validate the code in the first place. And you say how much of these features will be used by the vast majority of users? Probably not all of it. When I use, say, Python, I only use a bit of it. There are lots of functions, libraries, OOP features, etc. I have never used. But when I need them someday, they are there for me to use. Same goes for PHP. PHP is rich with features. It should be able to be flexible and adaptable to different situations. Sure, many users will not need or use these features. But there are also quite a few users who need these features to do something, and otherwise need fancy hacks and such to do them. PHP should cater to all its users: the people who don't know what objects and classes are, only use global variables, and have never used functions, and have no separation between model/view/controller; the people who use OOP and build simple class hierarchies, rarely needing things like reflection or interfaces; but also the people who use OOP extensively, with interfaces, big hierarchies, namespaces, traits, and so on, with all sorts of wonderful patterns that allow them to do amazing things. PHP is not the language of the newbie. PHP is not the language of the elite. It is the language of everyone who uses it, and it should cater to that. Who knows, maybe you'll end up using these features, some day. I know I keep harping on about it, but it still seems to me that there is no cohesive basic framework defined for the core functionality needed to run simple php scripts? SOmething on to of which all the esoteric bits can be added and explained without having to dig through numerous RFC's and release notes to see what the current state of play is :( Well, it depends. For me, the core PHP functionality for basic PHP scripts was PHP/FI 2.0. It has functions, variables, arrays, and mysql. And that's all I need, I suppose. For you, it might be PHP 3 or PHP 4. And that's why there is no cohesive basic framework defined for the core functionality needed to run simple php scripts. Because we all have different ideas of basic, simple and core functionality :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Andrew Faulds http://ajf.me/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Proposal: use SomeClass::staticMethod
Hello Internals! I'm just on and off luker here but thought I'll throw in an idea for a feature I'd love to see in PHP: aliasing static methods. Syntax would look something like this: use Namespaced\SomeClass::staticMethod; use Some\Foo::bar as fooBar; staticMethod(); // would call Namespaced\SomeClass::staticMethod() fooBar(); // would call Some\Foo::bar() This would make code more readable, by removing the the noise of repetition of class names. For use cases we can look at Java use cases for import static. Aliasing class constants like that would also be very nice. What does everyone think? Would it be possible in PHP? -- Giedrius Dubinskas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
Comments inline. On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas d.giedr...@gmail.com wrote: Hello Internals! I'm just on and off luker here but thought I'll throw in an idea for a feature I'd love to see in PHP: aliasing static methods. Syntax would look something like this: use Namespaced\SomeClass::staticMethod; use Some\Foo::bar as fooBar; staticMethod(); // would call Namespaced\SomeClass::staticMethod() Then you're confusing the reader, they think you're calling a function, but you're actually calling a class method. Confusion++ fooBar(); // would call Some\Foo::bar() What if a function called staticMethod() already exists, there'd be a bunch of confusion on referring to the right one. This would make code more readable, by removing the the noise of repetition of class names. For use cases we can look at Java use cases for import static. When you find a function call, you'd have to scroll up to the top of the page to see if it's actually a method alias. In this case being explicit is a good thing, no scrolling, no confusion. Aliasing class constants like that would also be very nice. What does everyone think? Would it be possible in PHP? -- Giedrius Dubinskas Not that I don't welcome your suggestions, I encourage them, but for this paritcular one I vote -1 on it. Thanks. -- 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] Proposal: use SomeClass::staticMethod
On Wed, Aug 15, 2012 at 12:59 PM, Giedrius Dubinskas d.giedr...@gmail.com wrote: Hello Internals! I'm just on and off luker here but thought I'll throw in an idea for a feature I'd love to see in PHP: aliasing static methods. Syntax would look something like this: use Namespaced\SomeClass::staticMethod; use Some\Foo::bar as fooBar; staticMethod(); // would call Namespaced\SomeClass::staticMethod() fooBar(); // would call Some\Foo::bar() This would make code more readable, by removing the the noise of repetition of class names. For use cases we can look at Java use cases for import static. Aliasing class constants like that would also be very nice. What does everyone think? I have the suspicion that you are just using static methods as a way to group functions into a namespace. If that's what you want, then why not just use namespaced functions for that? Should be a lot less confusing and also semantically more correct. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis dragoo...@gmail.com wrote: Comments inline. On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas d.giedr...@gmail.com wrote: Hello Internals! I'm just on and off luker here but thought I'll throw in an idea for a feature I'd love to see in PHP: aliasing static methods. Syntax would look something like this: use Namespaced\SomeClass::staticMethod; use Some\Foo::bar as fooBar; staticMethod(); // would call Namespaced\SomeClass::staticMethod() Then you're confusing the reader, they think you're calling a function, but you're actually calling a class method. Confusion++ fooBar(); // would call Some\Foo::bar() What if a function called staticMethod() already exists, there'd be a bunch of confusion on referring to the right one. This would make code more readable, by removing the the noise of repetition of class names. For use cases we can look at Java use cases for import static. When you find a function call, you'd have to scroll up to the top of the page to see if it's actually a method alias. In this case being explicit is a good thing, no scrolling, no confusion. Aliasing class constants like that would also be very nice. What does everyone think? Would it be possible in PHP? -- Giedrius Dubinskas Not that I don't welcome your suggestions, I encourage them, but for this paritcular one I vote -1 on it. Thanks. -- 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 Hi, To be honest, I'm not a fan of aliasing - and Paul supplied some of the reasons that stands for me. When one see an class / function declaration - I think that it'll make confuse if he/she'll have to look if this is an alias or not. Besides of that, there's still the issue of overriding existing functions rules which can confuse the user. Put that aside, if you can bring some example of good practice it'll be great :) Regards, Yahav.
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
2012/8/15 Stan Vass sv_for...@fmethod.com But variable typehints don't serve any such purpose. Actually, one could even say that they don't serve *any* purpose, short of providing the IDE with type information, because your code would work just as well even without the type check. If the type were wrong, it would just throw a fatal error when trying to do something with it (like invoking a method that does not exist). Just like with argument typehints. Point me to an argument typehint that is required for your code to run. Hi, Point me to an argument inerfaces are required. Or boolean (would could use 0/1 instead). Or abstract methods. Or function/methods parameters (we could use func_get_args()). Or default parameters. Or [insert random feature here]. Or: Point me to an argument, why the array of Foo shouldn't be a specialised class, that implements 'Iteratable'. With this your foreach problem simply disappear and everything, what remains, is something to make IDEs happy (with one line less to write...). My opinion Regards, Sebastian You and Stas keep giving arguments against argument typehints, which is really awkward. Stan -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
Hi, because it fits into the context (even if it's slightly offtopic): Can I throw in, that I would like to see autoloading for functions? :) Regards, Sebastian 2012/8/15 Nikita Popov nikita@gmail.com On Wed, Aug 15, 2012 at 12:59 PM, Giedrius Dubinskas d.giedr...@gmail.com wrote: Hello Internals! I'm just on and off luker here but thought I'll throw in an idea for a feature I'd love to see in PHP: aliasing static methods. Syntax would look something like this: use Namespaced\SomeClass::staticMethod; use Some\Foo::bar as fooBar; staticMethod(); // would call Namespaced\SomeClass::staticMethod() fooBar(); // would call Some\Foo::bar() This would make code more readable, by removing the the noise of repetition of class names. For use cases we can look at Java use cases for import static. Aliasing class constants like that would also be very nice. What does everyone think? I have the suspicion that you are just using static methods as a way to group functions into a namespace. If that's what you want, then why not just use namespaced functions for that? Should be a lot less confusing and also semantically more correct. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
Stan, On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass sv_for...@fmethod.com wrote: Hi! I agree with you. The one case where this syntax may be very useful is if we want to implement class casting. So introduce a pair of magic methods I do not think we want to implement class casting. I'm not sure how class casting even makes sense - if the object is of one class, how can you just make it into another class by casting? If you mean casting actually returns another object of different class, then just make a method for that that returns that object, I do not see how obscuring the purpose of this operation with unobvious syntax would help. The discussion is starting to drift very far from my original proposal. Instead of trying to guess what I mean, can't people just refer to my very simple definitive proposed behavior? My point was that what I posted was the only way that I can see for the original proposal to be useful. Anthony
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
On Wed, Aug 15, 2012 at 2:19 PM, Yahav Gindi Bar g.b.ya...@gmail.com wrote:
On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis dragoo...@gmail.com wrote:
Comments inline.
On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
d.giedr...@gmail.com wrote:
Hello Internals!
I'm just on and off luker here but thought I'll throw in an idea for a
feature I'd love to see in PHP: aliasing static methods.
Syntax would look something like this:
use Namespaced\SomeClass::staticMethod;
use Some\Foo::bar as fooBar;
staticMethod(); // would call Namespaced\SomeClass::staticMethod()
Then you're confusing the reader, they think you're calling a
function, but you're actually calling a class method. Confusion++
Static method essentially is a function (with elevated access to
containing class) so I don't see much of a problem here.
fooBar(); // would call Some\Foo::bar()
What if a function called staticMethod() already exists, there'd be a
bunch of confusion on referring to the right one.
Aliased static method would be translated during compilation and no
additional resolution rules would be required. If one would try to
define a function with same name in same file as alias, that would
result in fatal error just like with class aliases:
use Foo::bar as fooBar();
function fooBar() {} // Fatal error: Cannot redeclare ...
This would make code more readable, by removing the the noise of
repetition of class names. For use cases we can look at Java use cases
for import static.
When you find a function call, you'd have to scroll up to the top of
the page to see if it's actually a method alias. In this case being
explicit is a good thing, no scrolling, no confusion.
As of now when we see ``fooBar()`` we already have no idea where that
``fooBar`` declaration is. It may be declared in same namespace in
some other file, in global namespace in some other file or built in
function. I don't think that explicit alias in same file adds much
confusion to what we already have.
Aliasing class constants like that would also be very nice.
What does everyone think?
Would it be possible in PHP?
--
Giedrius Dubinskas
Not that I don't welcome your suggestions, I encourage them, but for
this paritcular one I vote -1 on it.
Thanks.
--
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
Hi,
To be honest, I'm not a fan of aliasing - and Paul supplied some of the
reasons that stands for me.
When one see an class / function declaration - I think that it'll make
confuse if he/she'll have to look if this is an alias or not. Besides of
that, there's still the issue of overriding existing functions rules which
can confuse the user.
Put that aside, if you can bring some example of good practice it'll be
great :)
I think a good example from top of my head would be PHPUnit testing
framework. It has class PHPUnit_Framework_Assert that contains only
static assertion methods like assertEquals(), assertTrue(), etc. Then
it has class PHPUnit_Framework_TestCase that extends
PHPUnit_Framework_Assert.
AFAICT there is no other reason for this hierarchy except to allow
shorter assertion syntax. Example from PHPUnit manual:
require_once 'PHPUnit/Framework.php';
class MessageTest extends PHPUnit_Framework_TestCase
{
public function testMessage()
{
$this-assertTrue(FALSE, 'This is a custom message.');
}
}
What is more PHPUnit_Framework_TestCase also contains methods
dedicated for mocking like once(), returnValue(), etc. Another
example:
class StubTest extends PHPUnit_Framework_TestCase
{
public function testReturnArgumentStub()
{
// Create a stub for the SomeClass class.
$stub = $this-getMock('SomeClass');
// Configure the stub.
$stub-expects($this-once())
-method('doSomething')
-with($this-lessThen('something'))
-will($this-returnValue(true));
$this-assertTrue($stub-doSomething('foo'));
$this-assertTrue($stub-doSomething('bar'));
}
}
Note that PHPUnit manual promotes using $this despide the fact that
these methods are ``public static``.
I think assertions and mocking could be decoupled and would be more
readable like this:
use PHPUnit_Framework_Assert::assertTrue;
use PHPUnit_Framework_Assert::lessThen;
use PHPUnit_Framework_MockObject_Matcher::once;
use PHPUnit_Framework_MockObject_Matcher::returnValue;
class StubTest extends PHPUnit_Framework_TestCase
{
public function testReturnArgumentStub()
{
// Create a stub for the SomeClass class.
$stub = $this-getMock('SomeClass');
// Configure the stub.
$stub-expects(once())
-method('doSomething')
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
Yes that is a very common use case and autoloading functions would solve that one but my main aim here is readability. And that said I would also suggest: use function Namespaced\foo; foo(); // calls Namespaced\foo(); ;-) -- Giedrius Dubinskas On Wed, Aug 15, 2012 at 2:26 PM, Sebastian Krebs krebs@gmail.com wrote: Hi, because it fits into the context (even if it's slightly offtopic): Can I throw in, that I would like to see autoloading for functions? :) Regards, Sebastian 2012/8/15 Nikita Popov nikita@gmail.com On Wed, Aug 15, 2012 at 12:59 PM, Giedrius Dubinskas d.giedr...@gmail.com wrote: Hello Internals! I'm just on and off luker here but thought I'll throw in an idea for a feature I'd love to see in PHP: aliasing static methods. Syntax would look something like this: use Namespaced\SomeClass::staticMethod; use Some\Foo::bar as fooBar; staticMethod(); // would call Namespaced\SomeClass::staticMethod() fooBar(); // would call Some\Foo::bar() This would make code more readable, by removing the the noise of repetition of class names. For use cases we can look at Java use cases for import static. Aliasing class constants like that would also be very nice. What does everyone think? I have the suspicion that you are just using static methods as a way to group functions into a namespace. If that's what you want, then why not just use namespaced functions for that? Should be a lot less confusing and also semantically more correct. Nikita -- 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] Proposal: use SomeClass::staticMethod
2012/8/15 Giedrius Dubinskas d.giedr...@gmail.com
On Wed, Aug 15, 2012 at 2:19 PM, Yahav Gindi Bar g.b.ya...@gmail.com
wrote:
On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis dragoo...@gmail.com
wrote:
Comments inline.
On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
d.giedr...@gmail.com wrote:
Hello Internals!
I'm just on and off luker here but thought I'll throw in an idea for a
feature I'd love to see in PHP: aliasing static methods.
Syntax would look something like this:
use Namespaced\SomeClass::staticMethod;
use Some\Foo::bar as fooBar;
staticMethod(); // would call Namespaced\SomeClass::staticMethod()
Then you're confusing the reader, they think you're calling a
function, but you're actually calling a class method. Confusion++
Static method essentially is a function (with elevated access to
containing class) so I don't see much of a problem here.
Don't know, how much I heard this, but: This is wrong! A function is a
standalone construct, without _any_ sideeffects, which means, that it will
always return the same result, when you give it the same input. I know,
that this is not completely true (see rand(), file related functions, or
functions build on top of (ugh...) globals), but thats not the point here.
Static methods have a well defined context and state: The class they are
defined in. This especially means, that they are explictly allowed to have
side effects (depending on the classes state).
fooBar(); // would call Some\Foo::bar()
What if a function called staticMethod() already exists, there'd be a
bunch of confusion on referring to the right one.
Aliased static method would be translated during compilation and no
additional resolution rules would be required. If one would try to
define a function with same name in same file as alias, that would
result in fatal error just like with class aliases:
use Foo::bar as fooBar();
function fooBar() {} // Fatal error: Cannot redeclare ...
This would make code more readable, by removing the the noise of
repetition of class names. For use cases we can look at Java use cases
for import static.
When you find a function call, you'd have to scroll up to the top of
the page to see if it's actually a method alias. In this case being
explicit is a good thing, no scrolling, no confusion.
As of now when we see ``fooBar()`` we already have no idea where that
``fooBar`` declaration is. It may be declared in same namespace in
some other file, in global namespace in some other file or built in
function. I don't think that explicit alias in same file adds much
confusion to what we already have.
Thats wrong: fooBar is either in the current, or in the global namespace,
thats all. It's extremely easy to find out, wether or not a function is
built-in or not (hint: Manual ;)). If it's a custom function, ok, then you
usually have to look at it, but I don't see, how this is a reason to make
it even more worse by adding the possibility, that it can be a method too.
Aliasing class constants like that would also be very nice.
What does everyone think?
Would it be possible in PHP?
--
Giedrius Dubinskas
Not that I don't welcome your suggestions, I encourage them, but for
this paritcular one I vote -1 on it.
Thanks.
--
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
Hi,
To be honest, I'm not a fan of aliasing - and Paul supplied some of the
reasons that stands for me.
When one see an class / function declaration - I think that it'll make
confuse if he/she'll have to look if this is an alias or not. Besides of
that, there's still the issue of overriding existing functions rules
which
can confuse the user.
Put that aside, if you can bring some example of good practice it'll be
great :)
I think a good example from top of my head would be PHPUnit testing
framework. It has class PHPUnit_Framework_Assert that contains only
static assertion methods like assertEquals(), assertTrue(), etc. Then
it has class PHPUnit_Framework_TestCase that extends
PHPUnit_Framework_Assert.
AFAICT there is no other reason for this hierarchy except to allow
shorter assertion syntax. Example from PHPUnit manual:
require_once 'PHPUnit/Framework.php';
class MessageTest extends PHPUnit_Framework_TestCase
{
public function testMessage()
{
$this-assertTrue(FALSE, 'This is a custom message.');
}
}
What is more PHPUnit_Framework_TestCase also contains methods
dedicated for mocking like once(), returnValue(), etc. Another
example:
class StubTest extends PHPUnit_Framework_TestCase
{
public function testReturnArgumentStub()
{
// Create a stub for the
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
Hi, This additional function seems little bit ... misplaced. :X Why not just use MyFoo\Bar; Bar\baz(); // -- Would be cool, if this trigger an autloader if required Except, that there is no autoloading everything already works this way. Regards, Sebastian 2012/8/15 Giedrius Dubinskas d.giedr...@gmail.com Yes that is a very common use case and autoloading functions would solve that one but my main aim here is readability. And that said I would also suggest: use function Namespaced\foo; foo(); // calls Namespaced\foo(); ;-) -- Giedrius Dubinskas On Wed, Aug 15, 2012 at 2:26 PM, Sebastian Krebs krebs@gmail.com wrote: Hi, because it fits into the context (even if it's slightly offtopic): Can I throw in, that I would like to see autoloading for functions? :) Regards, Sebastian 2012/8/15 Nikita Popov nikita@gmail.com On Wed, Aug 15, 2012 at 12:59 PM, Giedrius Dubinskas d.giedr...@gmail.com wrote: Hello Internals! I'm just on and off luker here but thought I'll throw in an idea for a feature I'd love to see in PHP: aliasing static methods. Syntax would look something like this: use Namespaced\SomeClass::staticMethod; use Some\Foo::bar as fooBar; staticMethod(); // would call Namespaced\SomeClass::staticMethod() fooBar(); // would call Some\Foo::bar() This would make code more readable, by removing the the noise of repetition of class names. For use cases we can look at Java use cases for import static. Aliasing class constants like that would also be very nice. What does everyone think? I have the suspicion that you are just using static methods as a way to group functions into a namespace. If that's what you want, then why not just use namespaced functions for that? Should be a lot less confusing and also semantically more correct. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
On Wed, Aug 15, 2012 at 4:54 PM, Sebastian Krebs krebs@gmail.com wrote:
2012/8/15 Giedrius Dubinskas d.giedr...@gmail.com
On Wed, Aug 15, 2012 at 2:19 PM, Yahav Gindi Bar g.b.ya...@gmail.com
wrote:
On Wed, Aug 15, 2012 at 2:09 PM, Paul Dragoonis dragoo...@gmail.com
wrote:
Comments inline.
On Wed, Aug 15, 2012 at 11:59 AM, Giedrius Dubinskas
d.giedr...@gmail.com wrote:
Hello Internals!
I'm just on and off luker here but thought I'll throw in an idea for a
feature I'd love to see in PHP: aliasing static methods.
Syntax would look something like this:
use Namespaced\SomeClass::staticMethod;
use Some\Foo::bar as fooBar;
staticMethod(); // would call Namespaced\SomeClass::staticMethod()
Then you're confusing the reader, they think you're calling a
function, but you're actually calling a class method. Confusion++
Static method essentially is a function (with elevated access to
containing class) so I don't see much of a problem here.
Don't know, how much I heard this, but: This is wrong! A function is a
standalone construct, without _any_ sideeffects, which means, that it will
always return the same result, when you give it the same input. I know,
that this is not completely true (see rand(), file related functions, or
functions build on top of (ugh...) globals), but thats not the point here.
Static methods have a well defined context and state: The class they are
defined in. This especially means, that they are explictly allowed to have
side effects (depending on the classes state).
That is an interesting thought but from my point of view just becasue
static method can access static class attributes does not imply that
static methods are or should be stateful. For me stateful static
methods just like stateful functions have their place (e.g. rand())
but its very limited and should not be considered common. I don't see
how stateful static method is any better then stateful function. If
you could share any resources that would convince my otherwise I'd be
like to learn that. Anyway I guess we are already drifting away from
the original suggestion... :-)
fooBar(); // would call Some\Foo::bar()
What if a function called staticMethod() already exists, there'd be a
bunch of confusion on referring to the right one.
Aliased static method would be translated during compilation and no
additional resolution rules would be required. If one would try to
define a function with same name in same file as alias, that would
result in fatal error just like with class aliases:
use Foo::bar as fooBar();
function fooBar() {} // Fatal error: Cannot redeclare ...
This would make code more readable, by removing the the noise of
repetition of class names. For use cases we can look at Java use cases
for import static.
When you find a function call, you'd have to scroll up to the top of
the page to see if it's actually a method alias. In this case being
explicit is a good thing, no scrolling, no confusion.
As of now when we see ``fooBar()`` we already have no idea where that
``fooBar`` declaration is. It may be declared in same namespace in
some other file, in global namespace in some other file or built in
function. I don't think that explicit alias in same file adds much
confusion to what we already have.
Thats wrong: fooBar is either in the current, or in the global namespace,
thats all. It's extremely easy to find out, wether or not a function is
built-in or not (hint: Manual ;)). If it's a custom function, ok, then you
usually have to look at it, but I don't see, how this is a reason to make
it even more worse by adding the possibility, that it can be a method too.
Aliasing class constants like that would also be very nice.
What does everyone think?
Would it be possible in PHP?
--
Giedrius Dubinskas
Not that I don't welcome your suggestions, I encourage them, but for
this paritcular one I vote -1 on it.
Thanks.
--
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
Hi,
To be honest, I'm not a fan of aliasing - and Paul supplied some of the
reasons that stands for me.
When one see an class / function declaration - I think that it'll make
confuse if he/she'll have to look if this is an alias or not. Besides of
that, there's still the issue of overriding existing functions rules
which
can confuse the user.
Put that aside, if you can bring some example of good practice it'll be
great :)
I think a good example from top of my head would be PHPUnit testing
framework. It has class PHPUnit_Framework_Assert that contains only
static assertion methods like assertEquals(), assertTrue(), etc. Then
it has class PHPUnit_Framework_TestCase that extends
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
Giedrius Dubinskas wrote: My main aim with this suggestion is readability. I'd like to remove unnecessary noise in code where it doesn't add any value to the reader. Code is easy to type (especially with good autocompletion) but it is read more often then typed and I think that is important. Or is it just me? Depends who is doing the reading? Since a static method should be provided with all the data it needs to produce a result, does it actually matter what it is called and how it is called? Of cause it does when one is trying to find the right descendent method of the class? I've already been told that the code I'm working on upgrading is archaic but it works fine. The bulk of the recent work has been pulling $this out of functions and creating a static section for many that handles the results of building a hash from the object, or supplying a ready built one. I'm told that it's bad practice to include the static functions within the class? But they are an integral part of processing the object, or are overridden by functions in the descendant objects. So 'staticMethod' has to be the right one for the object created, and SomeClass:: depends on the object being created. So how does the proposal cope with that type of structure? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
On Wed, Aug 15, 2012 at 6:54 PM, Lester Caine les...@lsces.co.uk wrote: Giedrius Dubinskas wrote: My main aim with this suggestion is readability. I'd like to remove unnecessary noise in code where it doesn't add any value to the reader. Code is easy to type (especially with good autocompletion) but it is read more often then typed and I think that is important. Or is it just me? Depends who is doing the reading? Since a static method should be provided with all the data it needs to produce a result, does it actually matter what it is called and how it is called? Of cause it does when one is trying to find the right descendent method of the class? I've already been told that the code I'm working on upgrading is archaic but it works fine. The bulk of the recent work has been pulling $this out of functions and creating a static section for many that handles the results of building a hash from the object, or supplying a ready built one. I'm told that it's bad practice to include the static functions within the class? But they are an integral part of processing the object, or are overridden by functions in the descendant objects. So 'staticMethod' has to be the right one for the object created, and SomeClass:: depends on the object being created. So how does the proposal cope with that type of structure? Sorry, I'm not sure I follow. Would it be possible provide some examples of what you mean? My proposal does not change anything to existing code. It only adds to readability where it is most desired. I picked PHPUnit example just to show that there is a desire for it in real world applications and in that particular case looks like inheritance was used (IMHO incorrectly) to reduce noise of prefixing class to each static method call for assertion and mocking matcher. With my proposal it would be posible to reduce this noise even more. I am not saying that this feature would be used everywhere nor that it should. But it would add a lot where it is already most desired. And FWIW for PHPUnit it would work out of the box. The static methods are already there. One would just need to ``use`` them :-) -- Giedrius Dubinskas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara ircmax...@gmail.comwrote: Stan, On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass sv_for...@fmethod.com wrote: Hi! I agree with you. The one case where this syntax may be very useful is if we want to implement class casting. So introduce a pair of magic methods I do not think we want to implement class casting. I'm not sure how class casting even makes sense - if the object is of one class, how can you just make it into another class by casting? If you mean casting actually returns another object of different class, then just make a method for that that returns that object, I do not see how obscuring the purpose of this operation with unobvious syntax would help. The discussion is starting to drift very far from my original proposal. Instead of trying to guess what I mean, can't people just refer to my very simple definitive proposed behavior? My point was that what I posted was the only way that I can see for the original proposal to be useful. Anthony Though I'm clearly in the minority on this, I for one think this proposal does have more merit than is being argued. There seems to be general agreement all around that this would provide a benefit as it pertains to code readability-- Not just by humans, but theoretically by doc/etc parsers as well. This is where we get into arbitrary, subjective territory. To me, that benefit in and of itself is sufficient to warrant this feature. To many of you, it is not enough. The tie-breaker for me is the fact that, though the benefits are modest, there's really no noticeable cost, either. The argument seems to, essentially, break down as follows: This feature isn't worth our time. Yes, it is! No, it isn't. There is clearly demand for this feature, even though its usefulness would be modest. Since it really wouldn't harm the language to just add it (if done correctly of course), my thinking is that we should just go ahead and add it. If nothing else, one benefit that hasn't been mentioned is the reduced traffic on Internals due to people no longer asking for it. ;) Just my three-and-a-half cents (damn inflation!). --Kris
Re: [PHP-DEV] Inline typecasting / typehinting for classes and interfaces
On Wed, Aug 15, 2012 at 8:15 PM, Kris Craig kris.cr...@gmail.com wrote: On Wed, Aug 15, 2012 at 4:48 AM, Anthony Ferrara ircmax...@gmail.comwrote: Stan, On Wed, Aug 15, 2012 at 3:57 AM, Stan Vass sv_for...@fmethod.com wrote: Hi! I agree with you. The one case where this syntax may be very useful is if we want to implement class casting. So introduce a pair of magic methods I do not think we want to implement class casting. I'm not sure how class casting even makes sense - if the object is of one class, how can you just make it into another class by casting? If you mean casting actually returns another object of different class, then just make a method for that that returns that object, I do not see how obscuring the purpose of this operation with unobvious syntax would help. The discussion is starting to drift very far from my original proposal. Instead of trying to guess what I mean, can't people just refer to my very simple definitive proposed behavior? My point was that what I posted was the only way that I can see for the original proposal to be useful. Anthony Though I'm clearly in the minority on this, I for one think this proposal does have more merit than is being argued. There seems to be general agreement all around that this would provide a benefit as it pertains to code readability-- Not just by humans, but theoretically by doc/etc parsers as well. This is where we get into arbitrary, subjective territory. To me, that benefit in and of itself is sufficient to warrant this feature. To many of you, it is not enough. The tie-breaker for me is the fact that, though the benefits are modest, there's really no noticeable cost, either. The argument seems to, essentially, break down as follows: This feature isn't worth our time. Yes, it is! No, it isn't. Every feature has a cost, even if that cost is just maintaining the code. Doing language changes for minority use cases, which already have sensible solutions, doesn't make much sense. Another aspect here is that there is no reasonable syntax for this feature, at least I can't think of one: * The syntax `$foo = (InterfaceName) $container-service` is completely out of question. It looks like a cast, but wouldn't actually do a cast. * Same is to be said about `InterfaceName $foo = $container-service`. This syntax implies that the $foo variable will always be of type InterfaceName, even if it is later reassigned. It's not a sensible syntax for a one time validation * The other three syntaxes that were mentioned were just as unclear. E.g. `$foo = $container-service as InterfaceName` again looks like a strange cast syntax and `$foo = $container-service is InterfaceName` looks like the assignment should evaluate to a boolean (i.e. `is` is some kind of `instanceof`). On the other hand, the current ways of accomplishing the same goal are well-established and easy to understand: * Using a docblock: /** @var $foo IntefaceName **/ * Using an assertion: assert($foo instanceof InterfaceName). I think that the assertion is a rather concise and clear way to do this. It is much more obvious than some new and obscure `$foo = (InterfaceName $container-service)` syntax. Nikita -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: use SomeClass::staticMethod
Giedrius Dubinskas wrote: On Wed, Aug 15, 2012 at 6:54 PM, Lester Caine les...@lsces.co.uk wrote: Giedrius Dubinskas wrote: My main aim with this suggestion is readability. I'd like to remove unnecessary noise in code where it doesn't add any value to the reader. Code is easy to type (especially with good autocompletion) but it is read more often then typed and I think that is important. Or is it just me? Depends who is doing the reading? Since a static method should be provided with all the data it needs to produce a result, does it actually matter what it is called and how it is called? Of cause it does when one is trying to find the right descendent method of the class? I've already been told that the code I'm working on upgrading is archaic but it works fine. The bulk of the recent work has been pulling $this out of functions and creating a static section for many that handles the results of building a hash from the object, or supplying a ready built one. I'm told that it's bad practice to include the static functions within the class? But they are an integral part of processing the object, or are overridden by functions in the descendant objects. So 'staticMethod' has to be the right one for the object created, and SomeClass:: depends on the object being created. So how does the proposal cope with that type of structure? Sorry, I'm not sure I follow. Would it be possible provide some examples of what you mean? My proposal does not change anything to existing code. It only adds to readability where it is most desired. I picked PHPUnit example just to show that there is a desire for it in real world applications and in that particular case looks like inheritance was used (IMHO incorrectly) to reduce noise of prefixing class to each static method call for assertion and mocking matcher. With my proposal it would be posible to reduce this noise even more. I am not saying that this feature would be used everywhere nor that it should. But it would add a lot where it is already most desired. And FWIW for PHPUnit it would work out of the box. The static methods are already there. One would just need to ``use`` them :-) Overriding just one version of 'staticMethod' with a shorthand is going to make working out WHICH version is being called all the more difficult to understand as one has to find a use clause to which it relates somewhere further up the code chain? Simply to identify the relevant block of code that is being actioned. In real applications (PHPUnit are not a real application only test case actions) there will be several occurrences of say 'getDisplayUrlFromHash' for the base class and for each specialised descendant class, so that referring to one via shorthand does not work practically. There may be special cases where it could be used, but that is just the sort of 'creep' that we need to avoid? At some point using the shorthand has to be replaced with the proper version simply because a different version of the code is needed. The main problem I have here is that having reworked the code to remove all the strict warnings/errors, I'm still not sure that the resulting code IS following the right rules, so it may well be that there is another way of building descendent static code that works more like you expect it to? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] removing an item from an array
How come there is no straight-foward obvious way to simply remove a given value from an array? Just look at the number of horrible ways people solve this obvious problem: http://stackoverflow.com/questions/7225070/php-array-delete-by-value-not-key Shouldn't we have something simple, like: array_remove($array, $value) : array (returns a new array) and/or array_delete($array, $value) : bool (modifies array directly) ?
Re: [PHP-DEV] removing an item from an array
Hi!
How come there is no straight-foward obvious way to simply remove a given
value from an array?
The same reason there's no simple way to undefine variable whose value
is 42 without knowing the variable name. Array is a container indexed by
keys, not values. So if you've got just a value, there's no way to know
if it's in the container at all, and if it is, where it is, except for
going through all the values and checking if any of them is equal to
what you nedd.
Just look at the number of horrible ways people solve this obvious problem:
I see:
if(($key = array_search($del_val, $messages)) !== false) {
unset($messages[$key]);
}
Nothing horrible here.
--
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
Re: [PHP-DEV] removing an item from an array
I like that chose 42 for the value. You win, and I completely agree.
On Wed, Aug 15, 2012 at 4:22 PM, Stas Malyshev smalys...@sugarcrm.comwrote:
Hi!
How come there is no straight-foward obvious way to simply remove a given
value from an array?
The same reason there's no simple way to undefine variable whose value
is 42 without knowing the variable name. Array is a container indexed by
keys, not values. So if you've got just a value, there's no way to know
if it's in the container at all, and if it is, where it is, except for
going through all the values and checking if any of them is equal to
what you nedd.
Just look at the number of horrible ways people solve this obvious
problem:
I see:
if(($key = array_search($del_val, $messages)) !== false) {
unset($messages[$key]);
}
Nothing horrible here.
--
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
Re: [PHP-DEV] removing an item from an array
On Wed, Aug 15, 2012 at 10:22 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
How come there is no straight-foward obvious way to simply remove a given
value from an array?
The same reason there's no simple way to undefine variable whose value
is 42 without knowing the variable name. Array is a container indexed by
keys, not values. So if you've got just a value, there's no way to know
if it's in the container at all, and if it is, where it is, except for
going through all the values and checking if any of them is equal to
what you nedd.
Just look at the number of horrible ways people solve this obvious problem:
I see:
if(($key = array_search($del_val, $messages)) !== false) {
unset($messages[$key]);
}
Nothing horrible here.
In addition to that, one should be aware that a value can exist
multiple times in an array, whereas keys are unique. So there are
infinitely many possible deletion strategies.
Btw, deleting all values (not just the first) is also very easy currently:
foreach (array_keys($array, $delValue) as $key) {
unset($array[$key]);
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
Btw, deleting all values (not just the first) is also very easy currently:
foreach (array_keys($array, $delValue) as $key) {
unset($array[$key]);
}
Even easier still, just do this:
$array_var = array();
--Kris
Re: [PHP-DEV] removing an item from an array
On Wed, Aug 15, 2012 at 10:29 PM, Kris Craig kris.cr...@gmail.com wrote:
Btw, deleting all values (not just the first) is also very easy currently:
foreach (array_keys($array, $delValue) as $key) {
unset($array[$key]);
}
Even easier still, just do this:
$array_var = array();
It's often overlooked, but array_keys has a second parameter that only
returns the keys for a certain value: http://php.net/array_keys ;) So
no, that does not clean off the whole array.
Nikita
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] removing an item from an array
On Wed, Aug 15, 2012 at 1:31 PM, Nikita Popov nikita@gmail.com wrote:
On Wed, Aug 15, 2012 at 10:29 PM, Kris Craig kris.cr...@gmail.com wrote:
Btw, deleting all values (not just the first) is also very easy
currently:
foreach (array_keys($array, $delValue) as $key) {
unset($array[$key]);
}
Even easier still, just do this:
$array_var = array();
It's often overlooked, but array_keys has a second parameter that only
returns the keys for a certain value: http://php.net/array_keys ;) So
no, that does not clean off the whole array.
Nikita
If you re-initialize it by setting it to array(), then yes that most
definitely will clear all the values in the array. As far as I know,
array_keys() has nothing to do with that.
--Kris
Re: [PHP-DEV] removing an item from an array
On Wed, Aug 15, 2012 at 1:35 PM, Kris Craig kris.cr...@gmail.com wrote:
On Wed, Aug 15, 2012 at 1:31 PM, Nikita Popov nikita@gmail.comwrote:
On Wed, Aug 15, 2012 at 10:29 PM, Kris Craig kris.cr...@gmail.com
wrote:
Btw, deleting all values (not just the first) is also very easy
currently:
foreach (array_keys($array, $delValue) as $key) {
unset($array[$key]);
}
Even easier still, just do this:
$array_var = array();
It's often overlooked, but array_keys has a second parameter that only
returns the keys for a certain value: http://php.net/array_keys ;) So
no, that does not clean off the whole array.
Nikita
If you re-initialize it by setting it to array(), then yes that most
definitely will clear all the values in the array. As far as I know,
array_keys() has nothing to do with that.
--Kris
Err nevermind, I think I misread what you were trying to do. If you want
to only clear a certain value, then yes using array_keys() with a search
value specified is the way to go. If you want to clear all values in the
array period (which is what I thought you were saying), then
re-initializing with array() makes the most sense.
--Kris
Re: Re: [PHP-DEV] removing an item from an array
On 2012-08-16 08:27, Nikita Popov wrote:
On Wed, Aug 15, 2012 at 10:22 PM, Stas Malyshev smalys...@sugarcrm.com wrote:
Hi!
How come there is no straight-foward obvious way to simply remove a given
value from an array?
Just look at the number of horrible ways people solve this obvious problem:
I see:
if(($key = array_search($del_val, $messages)) !== false) {
unset($messages[$key]);
}
Nothing horrible here.
Btw, deleting all values (not just the first) is also very easy currently:
foreach (array_keys($array, $delValue) as $key) {
unset($array[$key]);
}
$array = array_diff($array, [$delValue]);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] removing an item from an array
On Wed, Aug 15, 2012 at 7:59 PM, Morgan L. Owens pack...@nznet.gen.nzwrote:
On 2012-08-16 08:27, Nikita Popov wrote:
On Wed, Aug 15, 2012 at 10:22 PM, Stas Malyshev smalys...@sugarcrm.com
wrote:
Hi!
How come there is no straight-foward obvious way to simply remove a
given
value from an array?
Just look at the number of horrible ways people solve this obvious
problem:
I see:
if(($key = array_search($del_val, $messages)) !== false) {
unset($messages[$key]);
}
Nothing horrible here.
Btw, deleting all values (not just the first) is also very easy currently:
foreach (array_keys($array, $delValue) as $key) {
unset($array[$key]);
}
$array = array_diff($array, [$delValue]);
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
http://php.net/array_flip
This is my favourite way of removing a value:
$kv = array( 1 = 'a', 2 = 'b', 3 = 'c');
$vk = array_flip($kv);
unset($vk['b']);
$kv = array_flip($vk);
Re: [PHP-DEV] removing an item from an array
Am 15.08.2012 22:22, schrieb Stas Malyshev:
Just look at the number of horrible ways people solve this obvious problem:
I see:
if(($key = array_search($del_val, $messages)) !== false) {
unset($messages[$key]);
}
Nothing horrible here.
One thing that should be noted in this case and any solution that relies
on unset() is that even though its simple and fast, it will not result
in a properly indexed array. The same goes for any array_diff based
solution.
I tried and compared the following solutions and ordered them according
to their performance. The fastest (and with a correct result) solution
is based on array_slice. Why this is the case I can not say...I am not
arguing for another array-function (as there are so many already)...but
I certainly have my own array_remove implementation, since it's such a
common use-case.
function array_remove_slice($haystack,$needle){
while ( true ) {
$pos = array_search($needle,$haystack,true);
if ( $pos === false ) return;
$haystack = array_merge(
array_slice($haystack,0,$pos) ,
array_slice($haystack,$pos+1)
);
}
}
/* ~1.5 times slower than slice */
function array_remove_unset($haystack,$needle){
while ( true ) {
$pos = array_search($needle,$haystack,true);
if ( $pos === false ) break;
unset($haystack[$pos]);
}
}
/* ~2.3 times slower than slice */
function array_remove_loop($haystack,$needle){
$result = array();
foreach( $haystack as $value ) {
if ( $needle == $value ) continue;
$result[] = $value;
}
$haystack = $result;
}
/* ~3.5 times slower than slice */
function array_remove_diff($haystack,$needle){
$haystack = array_diff($haystack,array($needle));
}
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: Re: [PHP-DEV] removing an item from an array
This is my favourite way of removing a value:
$kv = array( 1 = 'a', 2 = 'b', 3 = 'c');
$vk = array_flip($kv);
unset($vk['b']);
$kv = array_flip($vk);
That doesn't make any sense. What if the values are present more than
once? array_flip will cause the keys to be overwritten.
$array = array('foo','bar','baz','baz');
$flipped_array = array_flip($array);
unset($flipped_array['foo']);
$array = array_flip($flipped_array);
var_dump($array);
Now your array is something completely different from what you wanted.
The solution stated earlier is the most sane one (just using
array_keys() with a search value).
The problem isn't very complicated and doesn't require a complex solution.
This thread is overstating a rudimentary problem (and that's the lack
of understanding PHP arrays).
Unlike most other languages PHP's arrays aren't really arrays, because
they don't create a list of values, but instead create an ordered
hashmap, which in-turn solves a wide variety of general problems such
as the ability to create dictionaries as well as ordered lists, which
-- when combining all general use cases that the PHP array aims to
solve -- is otherwise going to require having additional multiple
primitives for each use case.
For example in Python you need a combination of Tuples and Arrays to
achieve similar map structures. PHP aims to make this a more
simplified general use case primitive by abstracting away most of this
low-level work for you in the user-space code.
I don't wish to degrade anyone's contributions to this thread, but
this really is the perfect example of making a lot of fuss over
nothing on the mailing list and an example of the kinds of discussion
we should be avoiding when there are so many other important problems
we can solve.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
