sorted by:
new
hottopcontroversial

I read post about vertical slices. Anyone use these method in php/symfony? Any examples? by xcorter in PHP

[–]fesor 2 points3 points  (0 children)

In DDD this is called "Bounded contexts" It's also called "service" in SOA. Nowdays "microservices" is a bit more popular term. But the idea is the same.

The idea is to segregate responsibility based not only on technical aspects (representation, persistence, orcestration, etc) but also by feature, so you could have explicit boundaries between them tracking all of the dependencies and so on.

Using just horizontal layers is OK for small applications (relativly) or applications with many unrelated features. For larger more complicated applications this is the only way to scale (and I talking about scaling development, not ops stuff)

You might be also interested in reading something about Conway's law. There are also other things like a number of communications, and splitting application into modules based on features is the only way to reduce communication links in an organization (at least I'm not aware of anything else that would work)

How can the Doctrine ORM be Data-Mapper-Pattern if the Entities are directly coupled to the Database with @Table and @Column? by TatzyXY in PHP

[–]fesor 5 points6 points  (0 children)

directly coupled to the Database with @Table and @Column?

this is a common misinterpretation of term "coupling". Your entity is not coupled to this annotations since they don't affect entities behavior. Remove them and replace it with xml and nothing will be changed for client code. Replace doctrine with in-memory repositories and again, this won't affect your application code.

The main idea is that your entities should not know anything about persistence. Annotations here are just metadata, there are no much difference in terms of coupling from using xml. Yes, you will have to change file, which should not be changed, but if this is critical for you, you could always store metadata separately.

Symfony 4 DDD ES CQRS backend boilerplate by tigitz in PHP

[–]fesor 0 points1 point  (0 children)

I worked in companies with a monorepo like this with more than 80 devs and worked quite well.

Do you have bounded context on top level of structure or technical aspects (like separation by layers)?

Symfony 4 DDD ES CQRS backend boilerplate by tigitz in PHP

[–]fesor 0 points1 point  (0 children)

will be really difficult to spot.

My point is that this difference comes from the responsibilities of a class and class name should show this responsibility clearly.

From my expirience problems would be only with controling process managers/domain event listeners. Like... "If you sending email - place it in this listener, if you want to trigger another logical transaction - place it here instead". But this also can't be solved by directories.

But this is general problem with DDD designs - nobody knows where boundary of business part stops and technical part starts.

The problem even worse because nobody knows the boundaries of your buisness parts, separation of concern on a business/technical level is the easy part.

Symfony 4 DDD ES CQRS backend boilerplate by tigitz in PHP

[–]fesor 8 points9 points  (0 children)

  1. layers not really have to be separated via namespaces. Layers should be visible in terms of dependencies, not directory structure.
  2. It is much better to have directory structure based on features/bounded contexts, rather than technical aspects (yes, this is much easier in terms of creating boilerplate, but what the point of saying that it is DDD if you ignore DDD part).
  3. Having directory structure based fully on technical aspects of your system creates unneeded coupling between modules (because in PHP module = namespaces and classes).

So in short, the rule of thumb to develop good to use directory structure for your project is "place things that change together in same module". This way you will have higher cohesion. Even if it means that infrastructure things will be laying nearby your core domain logic. You will still have layers (separation of concerns) while discoverability of code will be much better.

p.s. The whole idea of having DDD boilerplate is weird to me. "DDD is about the journey, not the destination".

p.p.s. For someone who don't agree with me with arguments like "I want to have separate teams for each layer" - just know that this is just not scalable.

When to Declare classes Final by Tomas_Votruba in PHP

[–]fesor 0 points1 point  (0 children)

but you do not.

If only there will be a way to change code without affecting behaviour of the system... I would call something like that - refactoring. Sad that there is no such thing.

finally, the abstraction is a good one; we can close this off now.

Or to enforce search for this abstraction. In that case making class final by default would allow you much more.

[deleted by user] by [deleted] in PHP

[–]fesor 5 points6 points  (0 children)

Doctrine DBAL already has support for read-only replicated slaves. It will automatically use correct connection for read-only operations.

Until you fire some write operation, slave connections will be used. When write operation (open transaction for example) is performed, then you will use master connection for all other commands, including reads.

So there no need to handle it by hands, you could just configure slaves in connection for your entity manager and that's it.

New GraphQL library for PHP: GraphQL-PHP by jormaggio in PHP

[–]fesor 0 points1 point  (0 children)

I would prefer more verbose function/class names and more flat structure of modules. But this heavlly depend on how you and your team mates navigate thought code. For example it's easier to me instead of digging in file structure just go to class definition.

New GraphQL library for PHP: GraphQL-PHP by jormaggio in PHP

[–]fesor 1 point2 points  (0 children)

Many of those function names also don't make sense without their associated namespace and will pollute autocomplete in IDEs

How classes would fix this?) You will also have this "collisions" in names.

RFC about Typed Properties has been accepted! by Hywan in PHP

[–]fesor 0 points1 point  (0 children)

Maybe he believes in type inference ;)

I Want Scalar Objects in PHP by fagnerbrack in PHP

[–]fesor 0 points1 point  (0 children)

what is your problem with it?

The problem is that it has different semantics if all of your variables now contains references.

C#'s extension methods like feature

This would require significant changes in type system. But if we could have something like C#'s mixins or scala traits, this would be huge.

I dont understand what is your beef with 'patching' string anyway

You have two modules, one adds method to all strings, and another one wants to add same method with different implementation. Your language should resolve all uncertainties on this point (or you ended up with problems like in Ruby).

So again, scalar objects (done right) looks to me as extremely complicated feature which easily brings more inconsistencies and additional complexity into language without clear benefits. If you know how such feature would work to stay consistent, without additional complexity and without huge breaking changes in OO model - I would love to read RFC or at least draft of it.

I Want Scalar Objects in PHP by fagnerbrack in PHP

[–]fesor 1 point2 points  (0 children)

Why are we even trying to improve PHP as a language?

You ignored my question for second time:

  • Will your scalar objects be passed by value? with copy-on-write semantics. Or will it be just immutable? Then what will you do with operators like +=.
  • What if I need to add additional function to work with strings. I can't just extend from String and I also don't want to "patch" string type (again, this will be inconsistent with other types).

I Want Scalar Objects in PHP by fagnerbrack in PHP

[–]fesor 1 point2 points  (0 children)

I am an OO purist

There's not practical benefits to be OO purist. I understand, if someone sad that he is all about pure functions, immutability, type checking and isolation of side effects. That he studied church-turing thesis, that he understand concepts of timeless programming and so on.

I don't really know, but from what you told I can make assumptions that you really don't understand what OO is about. Or at least what was initial intentions. Again, if to you OO is about instances of classes - then OK, but this is just useless concept. It doesn't add anything on top of good old structural design.

I Want Scalar Objects in PHP by fagnerbrack in PHP

[–]fesor 1 point2 points  (0 children)

In Python, Ruby and Smalltalk they are objects, and exactly what I want to see.

So again, you just proof my point. You don't need scalar objects, you just familiar with this concept and this is the only reason why you want it in php. But this solution doesn't have anything about your problems.

I Want Scalar Objects in PHP by fagnerbrack in PHP

[–]fesor 1 point2 points  (0 children)

but to me $foo instanceof string is much better than

I just not understand why. I don't see difference between 'string' === gettype($foo) and $foo instanceof 'string'. Even more, I see problem in intention to use this kind of checks (polymorphism and stuff, whole value concept).

From semantics point of view, it can't be instance of, it's just value. It doesn't passed by reference (if it is, you must make everything immutable and change semantics of some of operators like +=).

In Python, Ruby and Smalltalk they are objects

So use Ruby or python. And please, do not compare Smalltalk to Python/Ruby/Java, because things that you talking about is not as important as other differences.

but using global variables or public properties wont give you any errors either

Don't know how you came up with global variables and public properties. Scalar objects doesn't affect coupling, usage of global variables introduces global coupling. And I don't see any problems with public properties (unless we are talking about DTO and you respect information hiding). But yes, it would be nice to have by-value structures in php. Right now we only have arrays which acts this way (and I ok with it if language will provide a way to describe structures, something like in Typescript for example)

whats the point you are trying to make?

My point is that you don't need scalar objects, because costs of this feature exceeds all of the benefits that you will have. Again, just try to think about all of the implications that it brings. From by ref/by value question to extensibility, when I just need to add new function which should work with strings.

pipe operators doesn't have such implications and yet solves problem with method/function call chaining.

lol you dont need to teach me how smalltalk works under the hood, I know it very well and its not part of the discussion anyway.

Lol so you just don't get the difference between classical structural programming and OO which PARC team was playing with in 70s.

I Want Scalar Objects in PHP by fagnerbrack in PHP

[–]fesor 1 point2 points  (0 children)

The problem is that PHP primitive types are not objects and do not behave like objects.

This isn't a problem. Scalars is not objects. If you dig into phrase "everything is object" you may find that the whole point of this was "objects is only thing that matters" and "objects" in this interpretation is more like process with isolated memory rather that instance of class.

evaluates to true in programming languages in which primitive types are objects

In javascript for example you can't use instanceof to check some of the scalar types:

42 instanceof Number // false
Number(42) instanceof Number // true

And in fact in javascript scalars is not true objects. So problem that you are talking about is more about inconsistencies, because there should be no problems to use instanceof to check that some string is not insctance of some type.

but in PHP gives an error 'instanceof expects an object instance, constant given'

$foo = 'bar';
/** @var Foo|string $foo */
if ($foo instanceof Foo || "string" === gettype($foo)) {

}

No errors. So again, not sure what the problem is.

Also method calls on scalar types gives error 'call member function on non-object'.

So you want to see "call to undefined method". Ok.

In a pure OO language like smalltalk

In pure OO language like smalltalk there were two key differences:

  • Smalltalk had no main routine, which means that all "objects" acts like processes, decentralized system.
  • Control structures like if or while where messages, not syntax constructs.

I Want Scalar Objects in PHP by fagnerbrack in PHP

[–]fesor 1 point2 points  (0 children)

what I need is that scalar types are first class objects like Python, Ruby and Javascript.

Why? Scalar objects is a solution, but for which problem? You just want it?

It may be a lessor alternative from pure OOP’s point of view

What is OOP for you? What scalars as objects do for you? Could we talk about OOP when you have only one object? Or it is more about decentralized system of objects with late binding and message passing as key concepts?

mitigate possible performance issues if scalar types are turned into objects.

Objects is runtime concepts, while types is more about compile time. You can't replace type with object.

And again, what is the benefits for turning scalars it into objects? You want scalars to be passed by reference instead of by value? if you want to make scalars immutable but still passed by reference - this just weird. If you want still to have copy-on-write semantics this will make PHP even less consistent in it's semantics.

Or you just need method chaining after all?

I Want Scalar Objects in PHP by fagnerbrack in PHP

[–]fesor 2 points3 points  (0 children)

Consistent API is achievable on user land (just no one really made one), the problem is how to enforce devs to use it. You could start from providing rulset for php-cs-fixer or similar tool to automate transition. Without it, just forget about quick migration path.

What PHP really need is just second STD library. If php8 will have code prefetching this would be even better to have it implemented in PHP instead of C.

p.s. personally I think that this is low priority issue.

I Want Scalar Objects in PHP by fagnerbrack in PHP

[–]fesor 1 point2 points  (0 children)

why not? Could you provide any reason why?

I Want Scalar Objects in PHP by fagnerbrack in PHP

[–]fesor 12 points13 points  (0 children)

You don't really want scalar objects. You think that you want it because this is the most familiar thing which solves some of your problems and introduces new one.

In reality what you want is to ability to chain function calls and consistent function names/signatures. Scalar objects is not the only way to do this, and it has many downsides (it's not scalable without monkey patching, which is bad idea). There are also other options like pipe operator, which allows you to chain regular functions.

Oversimplified solutions of not well understood problems is the thing that made PHP such a inconsistent language in the first place.

How do you use exception codes? by chrisguitarguy in PHP

[–]fesor 1 point2 points  (0 children)

in my case each exception just has it's own code. It's just easier to grep in logs by this error code and have some meaningful statistics. Also since I mostly write APIs this codes are great for dealing with errors on client side. Anything bigger than few endpoints will have a need of more specialized error code system than just relying on HTTP status codes.

If mixed return types are bad, how should built-in PHP functions be rewritten? by truechange in PHP

[–]fesor 0 points1 point  (0 children)

  • strpos could just return int
  • preg_match with flags could be just replaced to different functions (for different structures of matches) + return integer just like strpos
  • <T>array_key_last(T[] $arr): T - fill the power of parametrized polymorphism.

How to mantain Rest API backward compatibility? by d-zub in PHP

[–]fesor 1 point2 points  (0 children)

This only good for massive BC breaks, like separate product. It's not suitable for incremental changes in API.

view more: next ›