feature request: standard classes

[the-liquid-metal]

Hello. I think it is valuable if scalar_objects ships with standard classes, especially for codebase across multi project. I guess there will be a conflict if a project uses several library, and each of them uses their own classes. @HallofFamer has mentioned it on his post.

Some important things that must be considered are:

• each classes must contain all native function of their own type in order to suffices the basic need.
• there should be improvement of names used for methods, not just a copy of native name. it should be intuitive and consistent. Thumbs up if scalar_objects adhere to PSR2.
• equally important, the signature should be more consistent. scalar_objects does not need to follow the native. This way, it should have its own documentation in order to guide users.
• these classes by default are assigned to "register_primitive_type_handler".

If scalar_objects has standard classes, users just simply consume it, more often cocktailed it, and rarely entends it. I think by using traits is the safest way to avoid conflict, especially if the methods has prefix specific for each library.

// somewhere in someone code. foo acts as someone prefix.
namespace Someone\Util;
trait StringHandler {
    function fooMethod1() { /*1*/ }
    function fooMethod2() { /*2*/ }
}

// another guy code. bar acts as another guy prefix.
namespace AnotherGuy\Util;
trait StringHandler {
    function barMethod1() { /*1*/ }
    function barMethod2() { /*2*/ }
}

// my own code. my is mine.
namespace MyOwn\Util;
trait TStringHandler {
    function myMethod1() { /*1*/ }
    function myMethod2() { /*2*/ }
}

// my class definition
namespace MyOwn\Util;
class CStringHandler extends Nikic\StringHandler {
    use Someone\Util\StringHandler;
    use AnotherGuy\Util\StringHandler;
    use MyOwn\Util\TStringHandler;
    /* ... */
}

// if i am quite satisfied with standard class already provided,
// but my libs define its own, my class definition is
namespace MyOwn\Util;
class CStringHandler extends Nikic\StringHandler {
    use Someone\Util\StringHandler;
    use AnotherGuy\Util\StringHandler;
    /* ... */
}

// the magic is here:
register_primitive_type_handler('string', 'MyOwn\Util\CStringHandler');

note:

• standard class methods do not need to be prefixed, but library should.
• anotherguy is not bothered by someone because of his own StringHandler version, and vice versa.
• i have additional collections of method in my StringHandler. It means i have options whether i want to use them or just use my own.

To anticipate a very fat class of handler, i think it would be wise if scalar_objects provides additional methods (other than wrapper of native function), especially method which have functional style. As we know, php lack of functional style function/method. There are some libraries aim to cover this limitation. Some of them are just a clone of js library. A better thinking: provides functional style method of all procedural counterpart (if possible). The point is: don't give a room for users to reason that they need to extend it and litter the class.

[mikeschinkel]

While I love the idea of user-defined primitive type handling, I second this. I think we really should develop some standard base classes that people can use so that all the common functionality can be standardized.

OTOH, maybe this would happen through one or more PSRs?

[the-liquid-metal]

Class gives additional weight. Not all people agree with standard base classes. If not, this would have been done a long time ago. That's why primitive type handling which has class flavour is a brilliant idea. As a bonus, you get less keystrok when declaring variable. Rather than typed like this $mystr = new String("hello"), you only need to type $mystr = "hello", as usual. This is what JS do. The different is: in JS the variable is a real instance of class, but in PHP it is still primitive type.

[HallofFamer]

I was developing one in C myself(a package called Scalar Classes) before my old PC died and the data scientists failed to recover my lost files. I may be doing it again later this year, if I have enough free time.