Philosophy and Objectives about phpol HOT 17 OPEN

@naroga that would be interesting indeed.

So, we have two main distinct but connected objectives:

Wrap and Extend PHP in a Completely OOP Layer

Would that describe it well?

from phpol.

@hernandev @naroga most of PHP core functions for strings, array and numbers will return a new value, but again: that's because their accept primitives as the parameter, and only variables can be used as reference (and be changed as a side effect of the function).

I'm gonna to use replace and slug just as example here:

$input = new Str('Naroga Cordeiro');
$name = $input->replace('naroga', 'pedro');
$uniqueName = $input->slug();

$input is not just a variable, it's a value-object. $input holds a string that was entered by the user. Thinking like that, if you want the unique name, you want a new value-object. Then, the above example should be rewritten to $uniqueName = Str::from($input)->slug() if the object is mutable.

With immutability, every operation will generate a new value, so it's easy to understand why $uniqueName = $input->slug(). Also it's easy to associate $name = $input->replace() with $name = str_replace($input), because "immutability enables functional programming".

I vote to we have both implementations - mutable and immutable strings. I favor immutability (always), even with the performance penalty that concerns @naroga, but for the sake of the library, I think having both is more "developer-friendly", and because for now we're stuck with Str, but other components like Collections have way more points of discussion between mutable and immutable that most of the time end with whatever the developer chooses. But if we have to choose one, I stick with immutable.

from phpol.

Heres my IMHO.

1. Which components should be implement?

For instance, the basic ones.

2. Which components will be not or never implemented (like soap and imap libraries maybe)

We shall analyse the demand before start writing something new.

3. After the initial support, are we going to improve on already existent OOP native APIs? like DateTime?

If it is demanded, yes.

from phpol.

@lucasmezencio "So, IMHO, the ideia I had for it was to enable 100% OOP projects using PHP."

We will net get that far, since some stuff are not worth maintaining. But as a general moto, that should be enough.

Any other visions about it?

from phpol.

@hernandev, as an alternative vision, I'd like to create php-standard wrappers while still being able to add new data types and structures. In this vision, this would be an extension of the language, not a mere improvement.

The goal would be to allow anyone to implement anything already available in PHP-standard in an OOP fashion, more strictly and staticly typed, and with more data types and structures.

from phpol.

@naroga we have another issue to define the first components, so i Think both discussion can be done on this issue.

So, IMHO, the ideia I had for it was to enable 100% OOP projects using PHP.

Said that, as the general idea, we have 3 main things to discuss.

• Which components should be implement?
• Which components will be not or never implemented (like soap and imap libraries maybe)
• After the initial support, are we going to improve on already existent OOP native APIs? like DateTime?

So, i would suggest everyone involved to answer honestly the 3 questions and we continue from there.

from phpol.

I think that start from the beginning is a good idea.
So, think before act is one of my concerns.

from phpol.

@hernandev as we need to set a goal for this organization, discuss what are we going to do is more important than discuss what components will be implemented.

from phpol.

If we set the goal to create a "normalized object-oriented API" for PHP functions, this maybe be a quick library, because most of the SPL is OOP now (like SplFile, DateTime, PDO).

If we set the goal to create the same "normalized object-oriented API", but for Types, it became open to evolve in better ways, like Lists (evolution of array) and Currency (evolution of number).

from phpol.

"Which components should be implement?" is a question that I can't answer without defining the organization goals.

For example, I'm not sure if I want an Array component. Maybe I'd rather have a Collections component, with arrays, linked/double linked lists, ordered lists, dictionaries, and so forth. But maybe it conflicts with this organization's goals, which could be to just port the structured nature of PHP to a more OOP approach.

from phpol.

@naroga that's what I wanted to say with a "normalized object-oriented API for Types", but having then as extension of the initial wrappers (array, number, string)

from phpol.

Should we vow to try to emulate the PHP default primitive behavior where possible?

As an example, php strings are mutable. If we decide to add immutable-only strings, then we have actively deviated from the standard PHP behavior. Adding both kinds (mutable and immutable) wouldn't deviate much.

from phpol.

@naroga strings defaults to default variable behavior because they are not objects, the mutability is'nt something that applies there.

My problem with mutability is having to clone or instantiate new objects to keep state.

$name = new Str(//somewhere from request here);

$user = new User();
$user->slug = $name->slugfy();
$user->name = // shit, I can't set the name since it's a slug now

If we keep it mutable.

$user->slug = (clone $name)->slugfy();

so, I keep it strongly against mutability.

Also, I would like to add that: We should not try to keep it PHP Compliant since we're trying to provide alternatives to things WE DON'T LIKE.

So, whatever 'string is mutable' is a valid question or not, it should not matter since we should think about what will provide the best result.

from phpol.

we're trying to provide alternatives to things WE DON'T LIKE

Ok, I agree with that. However, in your example, your Str class is doing much more than being a simple value-object for a string, or a wrapper.

String mutability in PHP has never been "something I don't like", or something that I think should be fixed. Mutability is just something I take for granted from primitives (and it happens everywhere, there's not a single language a know, structured or OOP, that has immutable string objects by default). Now, if your Str class is going to do much more than simply perform standard string operations (strpos, str_replace, preg_match, etc), then tracking state would be much more coherent. I strongly dislike this approach, though.

I will repeat this as a mantra: A Str object should be an encapsulated representation of the string primitive. It should NOT be a we-can-do-anything-with-strings-and-thus-we-need-to-track-state. It should perform the basic string-datatype-related operations. Anything else (like slugify) should have its own namespaced function or formatter class.

If not for the semantic breach that I believe will take place if we deviate Str from the default php strings (and any other language strings, for that matter), I urge you to take the argument for performance reasons. Function invoking overhead is gigantic in PHP, and instantiating new objects at each operation is MUCH slower then instantiating new primitives.

This library will be slower then vanilla php. But it doesn't need to add a 400% overhead to a simple str_replace operation, if we ever want to see this adopted in the wild.

Now, I confess your example has made me doubt what my default expected behavior is.

$name = new Str('naroga');
$user = new User();
$user->nameWithE = $name->replace('a', 'e');
$user->name = $name;//do I expect to have a `naroga` or a `neroge` here?

I think either would be fine, but naroga would probably be the expected value from PHP, seeing str_replace returns a new string and doesn't modify the same reference.

I still don't know what to think about that.

from phpol.

@marcossffilho my Kudos for explaining what I've failed.

Indeed, str_replace would never change the subject, but return a new value.

I can't think of a clean API for string with mutable objects, the resulting client code would be catastrophic from my point of view.

If, we're implementing Str to be only a primitive-wrapper, I don't see the point of this.

We have a single solution that may not be elegant, and certainly would not be my first choice.

Here it is: group string related functions by objective, and use something like

$string->transform()->slug()
$string->transform()->replace()

that way, even tough is not beauty as I hopped for this when I first tough of it long ago, It would keep $string mutable for primitive-wrapper purposes and imutable for other operations.

Just my $0.02 for now

from phpol.

@marcossffilho that was the most compelling argument you've made, and I think I'm sold. Performance (and memory allocation) still concerns me, and I think we'd do well in having benchmarks, comparing str_replace to Str()->replace().

As of right now, I'm very inclined in having immutable as default, and not bothering implementing mutable strings at all, as their behavior would be completely different and could add confusion.

It just ocurred to me that we could port this to the core as a PECL extension later on and have this userland implementation as a polyfiller. Having this same syntax and behavior implemented in C would probably solve memory allocation and performance issues (most of them, at least).

Thanks for the great conversation.

from phpol.

@naroga that is something that I've tough about a little also, not sure if you guys remember on the beggining of our discussion but we could easily port this to zephir to make it a compiled extension.

The main idea now should be defining a dream-api that would make coding enjoyable, and them figure out how to make it real, and performatic

from phpol.