I mean, converting class into interface or vice versa is regular operation
in my codebase, and it doesn't make huge diff: using of a contract is just
the same.
On Friday, December 6, 2019 at 2:27:35 AM UTC+3, Daniel Plainview wrote:
>
> > I saw this being said above by Daniel Plai
> I saw this being said above by Daniel Plainview:
> You would still break BC for anyone who instantiates the Logger class.
True, but it breaks potentially less amount of code.
For example, it's a common to use bundles that instantiate services. So
these bundles may keep BC, but code
> Task - A Task is a specific case of an Event that is bidirectional.
I think this definition is not correct: Task (whatever it is) is not
specific case of Event, because Event is never bidirectional.
> Message - A Message is a specific case of an Event
Event is special case of a message (li
> commands and events are both events
are both messages*
On Friday, September 14, 2018 at 9:35:10 AM UTC+3, Daniel Plainview wrote:
>
> > In practice, the Message is essentially a command bus.
>
> This is kinda inaccurate language when you say that "message" is a &qu
> In practice, the Message is essentially a command bus.
This is kinda inaccurate language when you say that "message" is a "bus"...
But more importantly, message can be either command or event: why do you
make accent on "command" bus?
Command bus MAY return something (it doesn't violate CQRS:
h
> Plus, FWIW I recently decided to switch from one convention to another in
every new project I happen to work on, and I comfortably obtained the
suffix-less style by aliasing third party interfaces with a bunch of
`use` statements. Why can't you all do the same?
If you ask seriously, you can r
> I suppose I was thinking 'How should one implement for maximum
portability?'
The irony here is that singleton makes portability harder by itself.
This "pattern" be avoided as much as possible especially for external API
between libraries.
I don't see reason to standardize it.
On Monday, Febru
b\Adapter in
> order to work. If the Adapter fails to be created a
> MissingDependencyException would be thrown in that case
>
> On Tuesday, January 17, 2017 at 10:56:02 AM UTC-5, Daniel Plainview wrote:
>>
>> > This change is more in line with
>> &g
> This change is more in line with
> existing implementations, and focuses on the primary issue faced by
> consumers: determining when a service is missing from configuration.
In order to determine it, we look in our logs or at debugging page. We read
the exception message.
Different exceptions
> Essentially, the try/catch block MUST be present. This is specifying
> _internal implementation_, and, of more concern, specifying an
> implementation based on try/catch which has significant performance
> issues.
Do I miss something or it can be implemented easier w/o try .. catch?
Example
> If PR
> 1 is used, we end up with a call to get() raising a
> NotFoundExceptionInterface instance if either of the following
> conditions is true:
> - One of the dependencies of $id does not exist.
PR 1 doesn't bubble out NotFoundException in this case.
PR 2 acts like you described, though.
> Different error condition, different exception. In 20 years of writing
code I cannot recall ever saying "damn, this error message is too precise
and specific".
@Larry nobody says the opposite, we all agree on this one.
Of course, it must be different exception with nice and precise class name
> Btw, don't we miss an "InvalidArgumentException", to be thrown when the
arg passed to has/get is not a string?
It has as much value as documenting `@throws \Error` (compare it with
scalar type hints).
On Sunday, January 15, 2017 at 5:40:10 PM UTC+3, Nicolas Grekas wrote:
>
>
>
> Regarding you
> My main issue is that the current text says "In situation A, do X. In
situation B, do any capital letter that is not A." That is a construction
I simply cannot get behind in any specification of any sort, as it is
simply too vague and begs for inconsistent error handling
There is no such si
> Larry just gave one: better error handling.
You can use this argument for any exception.
Furthermore, I don't think it is correct to handle such "error" at this
stage.
You don't need to catch *exactly* this exception
(MissingDependency/Misconfigured), because you can't auto-fix it at runtime.
Some things make frameworks special and routing, in my opinion, one of it.
If you want to eliminate this uniqueness among frameworks, you make
pointless to choose between them.
> give maximum flexibility
> not be bound to an implementation
These are mutually exclusive statements.
On Friday, Nov
Sorry, I didn't read whole thread, but I don't think it's fair to compare
@throws and @triggers/@event/whatever.
@throws is a public contract supported by language.
It's not about documentation in the first place.
IDE (PhpStorm) reports me if I missed catch block for non-RuntimeException.
My cod
rvices may raise
> uncaught exceptions).
>
> Personally, I would handle missing services differently to a general
> container error and would be keen to see the spec reflect this, however, at
> this point I don't really feel strongly enough to spend any more time
> discuss
handled differently from service not being found.
>
> G
>
> On Wednesday, 23 November 2016 13:05:00 UTC, Daniel Plainview wrote:
>>
>> > These are different errors and could/should be handled differently.
>>
>> I think we all agree on this point. The question is d
y.
>
> G
>
> On Sunday, 20 November 2016 19:32:38 UTC, Daniel Plainview wrote:
>>
>> @Larry
>>
>> > Those would imply different people are doing something wrong, so it's a
>> different person's responsibility to fix.
>>
>> It is
onfiguration so it's in-scope for PSR-11, not PSR-11-followup.)
> Those would imply different people are doing something wrong, so it's a
> different person's responsibility to fix.
>
> --Larry Garfield
>
> On 11/11/2016 01:42 PM, Daniel Plainview wrote:
>
>
> In the eyes of interoperability and standard, unless there's a strong and
compelling reason to add "UTF-8" to the spec, why specify a character set
at all? What benefit is there in artificially limiting the available
strings?
Quick example: you want to log every service names that were called
> Could you, please, provide us a real use-case when you need to catch
DependencyNotFoundException?
Or MisconfiguredServiceException, whatever :)
On Friday, November 11, 2016 at 9:42:11 PM UTC+3, Daniel Plainview wrote:
>
> > So why even mention it then?
>
> I think
ned
> exception for group 1, a clearly defined parent exception for group 2
> (subclasses specific to a given implementation entirely welcome), and group
> 3 is not-our-problem.
>
> --Larry Garfield
>
> On 11/07/2016 12:20 PM, Daniel Plainview wrote:
>
> The major problem with u
ontainerExceptionInterface
> (thrown if the requested service is defined, but for whatever reason can't
> be instantiated)
>
> And implementers are free to subclass the latter if they choose, but must
> still have that exception flag on them. (I'm flexible on the name, the
> A situation of "if your child container throws exception X, you're
required to catch it and turn it into anything that's not X but is still Y"
seems needlessly convoluted
You did it by introducing "child container", Container contract doesn't
have any child containers, this contract is very s
> but because it doesn't know that it's a child it just throws "I don't
have it", which gets thrown all the way up to the initial caller, who goes
"wait, wat?"
It would be considered as bugged PSR-11 implementation.
> then it needs to wrap that inner Not-Found with... something. That
somethi
If you need to know whether dependency of a service is missing and you have
some special logic behind it... What about
DependencyArgumentTypeMismatchException, MissingRequiredArgumentException
and tons of others container-is-screwed exceptions? What makes them less
important?
(question to Lar
What do you mean? The namespace is simple "Psr\Container". It doesn't
clarify domain.
On Wednesday, October 5, 2016 at 5:19:40 AM UTC+3, Woody Gilk wrote:
>
> Why should a class name contain information that is present in the class
> namespace? If you don't like the class name, there is the opti
> By my calculations, getting people to agree about smaller, isolated
abstractions should be a lot easier than getting people to agree on a
larger, combined package of abstractions.
You state that general-purpose URI is "smaller, isolated abstraction".
However, in general case, you have to thi
It is not great rationale, they might say "see, C# has a prefix convention,
C# is younger language, etc.".
Most of people don't want to step out of their comfort zone with suffix
convention, that's it.
On Monday, September 12, 2016 at 12:30:44 PM UTC+3, Dracony wrote:
>
> > This discussion has
By the way, why PSR-8 has (had?) naming without suffix?
https://github.com/php-fig/fig-standards/blob/master/proposed/psr-8-hug/psr-8-hug.md
Huggable, GroupHuggable.
Why not HuggableInterface then?
On Wednesday, August 24, 2016 at 11:29:52 PM UTC+3, Daniel Plainview wrote:
>
> Som
Sometimes suffix has influence in design decisions, because it hides some
design issues which cannot be said about tabs-vs-spaces. This comparison is
not correct.
On Wednesday, August 24, 2016 at 4:49:42 PM UTC+3, Larry Garfield wrote:
>
> On 08/24/2016 07:58 AM, Art Hundiak wrote:
>
> I find it
This conversion (like some others in this group) looks like the following:
— Why do we need X?
— Because we can do Y with it!
— Are you sure that Y is a good thing?
— *no answer*.
— OK, let's keep X.
Just for clarity, arguments for this exception are:
* "PEAR most definitely wants to keep the p
Consistency is a matter of time.
If PHP-FIG promoted suffix-less convention, majority of projects would
change it as well.
Existing PSRs are not supposed to be relevant forever. They may be
deprecated and replaced in the future.
By the way, technically, it is possible to fix it with BC
with htt
I'm afraid original decision was made by inertia and without proper
discussion.
As you can see from this thread, people find difficult to describe pros of
the suffix,
apart from:
* it informs consumers that they are type hinting against an interface (IDE
informs as well; and from my experience
HttpRequest is not good name, because Request from PSR-7 is already
HTTP-request.
However, when I asked community about lack of different
implementations, Matthew Weier O'Phinney said the following (
https://groups.google.com/forum/#!topic/php-fig/RQuMBMD48zU):
> Guzzle has traditionally focuse
e?
The thing is implementation name is not significant. You program to an
interfaces, not implementations.
On Thursday, August 18, 2016 at 5:04:33 PM UTC+3, Woody Gilk wrote:
>
>
>
> On Thursday, August 18, 2016 at 3:31:16 AM UTC-5, Daniel Plainview wrote:
>>
>> Also, you woul
My bad, I thought your "makes it more comfortable" was in favour of keeping
suffix. I mean, this should not be comfortable. ;)
On Thursday, August 18, 2016 at 5:00:17 PM UTC+3, Erik Landvall wrote:
>
> @Daniel Plainview | thanks for your feedback, but I don't know if you
> I'm all in favor for noise reduction in my code, but couldn't really see
any solution to the conflicting name conventions I faced
Please, read messages above.
> Why *specific* implementation has *non-specific* and generic name? Yet
another point for removing suffix: it forces to think about i
> As some of them pointed, it gives more clarity that it is an interface
than a concrete implementation
Ironically, I think this is disadvantage: you don't need to know about it.
Further, if you don't allow inheritance like this: final class Logger, you
would be allowed to convert Logger into a
> There are all sorts of unexpected exceptions that an underlying
implementation might throw
Why you do expect (catch) unexpected exceptions? What does catch block
contain? What's the difference with catch (\Exception)?
On Wednesday, August 17, 2016 at 5:35:01 PM UTC+3, Larry Garfield wrote:
>
> Having said that, if someone wants to do the research and come up with an
actual count of which member projects use an Interface suffix, and which do
not, I'd be open to modifying my stand depending on the results.
This argument is weak. Majority can be wrong.
On Wednesday, August 17, 2016
> How do you propose to resolve this common problem?
It means that Diactoros has naming issue. Why *specific* implementation has
*non-specific* and generic name? Yet another point for removing suffix: it
forces to think about implementation name more.
Also, I suggest to read
this: http://verra
> Clicking reply on a mail client I start writing 1/10th of a second
> later. On a forum it takes at least 10-20 seconds to load.
Please, fix you net and upgrade computer, respect yourself.
We shouldn't tolerate racism and slow computers.
On Friday, August 5, 2016 at 12:19:52 PM UTC+3, Alessand
rrent users of it. (There are multiple PSR-6 implementations already in
> the wild, and no doubt projects using them.)
>
> Whatever the arguments for an exception may be, I don't think we can
> consider them without a BC break.
>
> --Larry Garfield
>
>
> On 07/26/2016 04
> Throwing `\InvalidArgumentException` is
> another widely used alternative, however, that would be a change in the
> specification (as Calling Libraries would then need to know to catch that
> exception as well).
Let me disagree. Why Calling Libraries have to know about it? Why Calling
Libraries
> For one thing: This mailinglist is already available via a forum-like
interface at GoogleGroups.
I find this interface not user-friendly.
Email messages are not really supposed to be parsed automatically,
they are supposed to be "parsed" by human beings in the first place.
I think it's fundam
confusion, second part of my message was directed
to participants above.
On Saturday, July 9, 2016 at 4:23:42 PM UTC+3, Stefano Torresi wrote:
>
>
>
> Il giorno sab 9 lug 2016 alle ore 14:43 Daniel Plainview <
> daniel...@gmail.com > ha scritto:
>
>> > like a generi
> like a generic CommandBus rather than a CLI specific one
Please, don't mix up things. CommandBus has nothing to do with CLI Command.
CLI Command is just UI detail exactly like HTTP controllers.
They are not place for business logic.
This problem is already known as
https://en.wikipedia.org/wik
Question to Dracony as the only active Sponsor of this PSR: what will
happen next? What's the current state of this PSR?
On Thursday, March 10, 2016 at 1:42:19 AM UTC+3, Dracony wrote:
>
> I can be either coordinator or sponsor for this one if you like.
> On Mar 9, 2016 23:38, "Michael Cullum" >
I'm sorry for these typos, I have to read my own message several times
before posting.
On Monday, June 27, 2016 at 10:27:40 PM UTC+3, Daniel Plainview wrote:
>
> > PHP provides a DateTimeInterface and multiple implementations thereof,
> so some programmers *do* want different i
's HttpFoundation provided a
> few subclasses of Response for common use cases (like BinaryFileResponse,
> JsonResponse, and RedirectResponse). A PSR-7 library might choose to
> implement something similar.
>
> On Monday, June 27, 2016 at 11:12:55 AM UTC-7, Daniel Plainview wrote:
The problem is some things shouldn't be framework-agnostic, because they
*are* framework.
They are what make us to choose one framework in favour of another.
Here is place for personal preferences.
I'd be careful with proposals like "because we can".
On Monday, June 27, 2016 at 10:57:46 AM UTC+3,
> I'd say that the variety of stream implementations is one of the reasons
someone would opt to use Guzzle's PSR-7 library instead of another, so it
seems to directly answer the original poster's question
No, it's not.
Please, pay attention that I talk about *value objects* Request and
Respons
y
wrote:
>
>
> On Jun 20, 2016 3:47 PM, "Daniel Plainview" > wrote:
> >
> > Hello,
> >
> > The one thing in PSR-7 still bothers me: do different implementations
> truly exist?
>
> Of the top of my head: Diactoros, Guzzle, and Slim, a
Sorry for typos, btw.
These mailing lists, eh...
On Friday, June 24, 2016 at 11:39:55 PM UTC+3, Daniel Plainview wrote:
>
> Hi,
>
> I'm glad to see that you raised similar questions.
>
> It definitely makes sense to make some research on this topic and find out
> d
it will
> be documented. If there are no reasons, then maybe it's worth discussing
> standardizing an implementation?
>
> Matthieu
>
> Le mardi 21 juin 2016 10:15:59 UTC+2, Daniel Plainview a écrit :
>>
>> > Guzzle has traditionally focused on client behavi
n is if these
differences are "true" and "valid"?
They differ in terms of lack of validation (if you mean that case with
withHost()).
It reveals design issue: they shouldn't differ here; they should behave the
same.
On Tuesday, June 21, 2016 at 6:59:13 AM UTC+3, Mat
Hello,
The one thing in PSR-7 still bothers me: do different implementations truly
exist?
Or in other words: how these implementations may differ in terms of
behaviour?
If they don't really exist, so why PSR-7 doesn't provide Request/Response
classes?
I'll try to bring my point through imagina
60 matches
Mail list logo
