I was never really sure what a URI spec was supposed to be, and as Michael says a URI is just a string, so in regards to this PSR it shouldn't really matter.
--To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/da850064-3520-435b-8f9a-2735b1f9641a%40googlegroups.com.
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
This all seems very interesting, but I'm unclear on what exactly would be standardized by this and how it'll help with interoperability. This isn't to say that I don't think it'll help, just that I literally have not seen this explained anywhere. Is there any chance someone can comment on that a little bit, and speak to what the goals here would be?
Robert
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/0391c0c9-caff-4a2a-afe4-5ac0f134771f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/d8323f16-c5c4-42e8-af15-d3bbaea5f726%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/5361ABCE.4010501%40garfieldtech.com.
This just caught my eye and I'd encourage to read my rant on fluent interfaces at http://ocramius.github.io/blog/fluent-interfaces-are-evil/ (which I've already spammed everywhere)...
Unless there's a VERY strong reason to have a fluent interface (copy on write, for example), then I wouldn't include it at all.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/4575b823-ac1c-4668-9412-373c87776b1f%40googlegroups.com.
Sure, I've seen ugly fluent interfaces. There is no coding technique ever created that cannot be used to create an incomprehensible crime against nature itself. That's not the point.
My general guideline is this: If a method has something useful/meaningful to return, do so, whatever that is.
If it has nothing meaningful to return, return $this so that one *could* chain method calls if one were so inclined.
Given the option between returning NULL (utterly useless)
and $this (optionally saves some typing and can make code easier to read if not used stupidly), always return $this.
Because being utterly useless is for suckers.
For *most* setter methods (by no means all), there's rarely anything useful/meaningful to return.
So return $this so that you can chain if you feel like it. If you don't feel like it, cool, no harm done.
An "undefined" return type is a dead end. I don't like dead ends.
Hi Larry,
Answers inline:On 25 May 2014 04:21, Larry Garfield <la...@garfieldtech.com> wrote:
Sure, I've seen ugly fluent interfaces. There is no coding technique ever created that cannot be used to create an incomprehensible crime against nature itself. That's not the point.
My general guideline is this: If a method has something useful/meaningful to return, do so, whatever that is.The point is exactly this: returing `self` for no reason carries no semantical meaning, and instead drags some problems with itself (linking the rant about that as a cross-reference, in case anyone missed it: http://ocramius.github.io/blog/fluent-interfaces-are-evil/ ).
`self` is not the "result" of an operation, therefore it should not be returned unless really required.
Your setter methods are accessors for a property, they does not produce any result.If it has nothing meaningful to return, return $this so that one *could* chain method calls if one were so inclined.I've just said what "meaningful" means here, and `@return self` is not "meaningful".This is not the point of an interface. An interface is a contract, and the contract states what goes in and what comes out, and that is not to ease development, but to set strict constraints on what is allowed and what isn't
Chaining operations is not something that makes your interface safer or more useful.
Given the option between returning NULL (utterly useless)We're not returning `NULL`, the method is simply `void`. There is a difference between `@return null` and `@return void`, which is that `@return null` basically "allows" for consumers to use the result of the operation (though indeed useless), while `@return void` defines that consumers SHOULD NOT use the result of the operation.
PHP is not strictly typed, but assigning the result of a `void` expression to a variable in strictly typed languages is a compiler error (as it should be).
This is purely academic and more irrelevant to the conversation than the other talk of fluent stuff was.
It's not your place to suggest that fluent is a good way to do things or a bad way to do things.
At best this interface would be indifferent to them as PHP interfaces do not currently support return types, so we can say do whatever you like,
or we can accept that getters get things and setters are fluent - like every single PHP class and package I can remember using in the last few years.
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CADyq6s%2BsCy4VQsqj%2BzrV9evsuer0hDJ0GN6%2B_RP02CBiih5xNA%40mail.gmail.com.
I always propagate to avoid fluent interfaces as long as one don't want to introduce a DSL. It only leads to bad habits. And that only to save some characters...
- What is the definition of "When a method has something useful to return"? Every method, that returns 'void' should return the current insurance instead? What happens, when the method can return something "useful" in the future? This is impossible and anyway would be confusing with other fluent methods.
- what if the context changes? One method returns a different instance? Now in a long chain of method calls we have a context change everybody needs to be aware of.
- who defined, what a "useful return value" is? A setter can always the old value instead.
I can find more, but at the end: all this only to save some characters?!
So as a non-voter I really prefer to rather discourage this, than recommend it. It only leads to bad behaviors.
Regards,
Sebastian
>
> --Larry Garfield
>
> --
> You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
> To post to this group, send email to php...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/538153C3.1090404%40garfieldtech.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CALtuQzDNVhrFp3QOy-ZWqVZMR-EC8zdA_FjaEmJK78H24-114g%40mail.gmail.com.
On 26 May 2014 04:20, Phil Sturgeon <em...@philsturgeon.co.uk> wrote:
This is purely academic and more irrelevant to the conversation than the other talk of fluent stuff was.Please don't be the DHH of the situation. Academic knowledge works, otherwise it wouldn't be passed on. I just felt something was wrong and told why it is so. If it is irrelevant to you, then keep it that way, but `null` and `void` are different, and PHP turns out to be always returning `null` when a method is `void`. Yes, that's an engine thing, still different for the annotations.
It's not your place to suggest that fluent is a good way to do things or a bad way to do things.Pardon me, this may be a language barrier issue, but I think there are more explicit ways to say "shut your mouth".
If feedback is not welcome on this mailing list, then just say so and I'll keep lurking instead of trying to be helpful.
Isn't this a discussion list? Or maybe is it just for the votes? Did I miss something? Anyone?
At best this interface would be indifferent to them as PHP interfaces do not currently support return types, so we can say do whatever you like,
Wrong. We trust the return types, even if they aren't enforced by the engine.
[snip]
or we can accept that getters get things and setters are fluent - like every single PHP class and package I can remember using in the last few years.Trends change, and TBH, I didn't find anything concrete (written/blogged/published) about why fluent interfaces are a smell, so that's why I felt the need to write it down.This doesn't mean that what I write should be taken for granted, but that little thought has been put in fluent interface smells in the past (I think there's something about it in "Effective Java", but I'm not really sure).
That's why you probably have that many fluent interfaces coded without previous thoughts put in "why" making them fluent.
Just like Larry said above, we've been (are) doing it blindly for no proper good reason.
Yes, there are bigger problems, but this is still a problem, and it can be solved immediately.
Fair enough? :)
I started to say that a compromise here would be to allow for including a FluentDooblyGooblyInterface alongside any DooblyGooblyInterface, where the difference is "return void => becomes => return self". However, the proliferation of additional interface definitions to just allow this one behavioral difference feels like a code smell to me. Thinking further, would a FluentAwareInterface of just isFluent(boolean $flag) be a useful structure, where the PSR requirement for using that interface is that any "return void" behavior in an implementer is required to check that flag and "return self"? By moving the behavior distinction into an interface definition, then an implementer of some other interface can just list itself as also implementing FluentAwareInterface.
I'm not fully convinced here just yet, as this either requires a further documentation requirement for the implementer of "@return void|self", or it means a documented "return void" allows for a semi-undocumented "return self". Thus, consider this a brainstorming thought that I'm throwing against the wall ;-)
Evert
--
You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/53A30669.1%40gmail.com.
Would __call() get executed if the named method exists? I thought it was only used in the case of a non-existing method name being called at runtime.
On 19 June 2014 17:52, Chuck Burgess <demon...@gmail.com> wrote:Would __call() get executed if the named method exists? I thought it was only used in the case of a non-existing method name being called at runtime.
I just patched up an example to show how this would work: http://3v4l.org/Xj719