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 Plainview
> 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 whic
> 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
> 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:
> 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
> 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,
pter 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
>> > exis
> 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?
> 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,
> 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
> 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
> 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
> 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,
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 do you need
>> expl
t; 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 already clear. If i
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:
>
> > So why even mention it then?
>
>
ception 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 unchecked exceptions is that it is not class
> consumer b
ever 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 one
> I have there is likely not the best name.)
>
> --Larry Garfield
>
> On 11/05/
> 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
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
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
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
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
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
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
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 wouldn't be al
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
> 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:
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:30 PM
> 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
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 generic Com
> 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
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
> 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
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
> differ
e 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 behavior, and has
>>
39 matches
Mail list logo
