Philosophy and Objectives

[naroga]

Hi.

I see we've created a few repositories, some with sample code. I'd like to discuss a few things, before we get hands-on.

What's the goal of the library? Is it to port the structured nature of PHP to a more OOP approach? Or are we going to take the chance to enhance it, somehow?

This is a very important discussion before the hands-on. For example, I see someone has created an Array repository. If we are to enhance the native types, should we not discuss Arrays x Collections? Collections packages, similar to System.Collections from .NET provides, could implement not only arrays (which would be a collection type), but also ordered lists, linked lists, dictionaries, and others.

Can we take a moment to talk about those issues?

[hernandev]

@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.

[lucasmezencio]

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

[lucasmezencio]

@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.

[pedrommone]

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.

[filhocodes]

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).

[hernandev]

@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?

[naroga]

"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.

[naroga]

@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.

[filhocodes]

@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)

[hernandev]

@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?

[naroga]

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.