should type conversion be part of phpcr or rather phpcr-utils?

[David Buchmann]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

as the jcr people start discussing to finalize jcr 2.1 of which phpcr
will be part, i think its time we clean up our remaining issues here.

the list is here
https://github.com/phpcr/phpcr/issues

i think the event listener thing is less important. but the query
object model seems to need a review. anybody up for that?

the other worrying thing is the PropertyType::convertType method.

this is a rather big method to convert between all phpcr types:
https://github.com/phpcr/phpcr/blob/master/src/PHPCR/PropertyType.php#L443

as some of this seems non-trivial (we still have bugs in it) i wonder
if the PHPCR api is really the right place for it. once PHPCR is
released, it will be hard to change anything about it.

we could say this is rather the job of the implementation and move the
methods to phpcr-utils, which are optional and implementations are
free to not use it. it will be a lot easier to release fixed versions
of phpcr-utils.

should we move the method? should we even make it a non-static method
and in jackalope access a type converter from the factory or the
object manager, to make it easier to extend behaviour?

cheers,david
- --
Liip AG // Agile Web Development // T +41 26 422 25 11
CH-1700 Fribourg // PGP 0xA581808B // www.liip.ch
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJReXxGAAoJED/JtliXIA4s228H/1wvu0s3yT8AOfkeri1uGaAQ
nZAmzoQGocv9/DT9a/JIJ7E3hay1tXpPifFAOT/A8TumlzBr9EbfiKcQuZa5t0EU
2WmaNzhPYZGO7Y97rf03vMZtkApsJwtX5AEDjzUSF3cJIRVR9yPplRcq6Wg9hRkh
UOPZGd6Usi2R4qfkT2BYRAIKKUQKdJ2sr4vr9AopfN1cad31nqqCT6U/1hb9X/Se
b//gR1x1Eldj5aeN2+BYiRg4pCEGjAeRlk099PJTvQ6Ipi/jGDVLCyfk0rpd8tcM
OVGrT9V1nXbFC/9q4S0MP2k8AKT8GTMbCkUuCGVTlolesPGH8ZBb/GwcfVZf3Dw=
=A1pS
-----END PGP SIGNATURE-----

[Willem-Jan Zijderveld]

Hi,

I think moving it to Utils makes sense.
Would we need a transition period where PHPCR still has the method (with @deprecated) that acts like a proxy to the Utils?

Not 100% sure about the converting to non-static. I usually try to avoid static methods as much as possible, but for Util functions it usually makes some sense.

Greetings,
Willem-Jan

David Buchmann

April 25, 2013 8:56 PM

[David Buchmann]

> I think moving it to Utils makes sense.
> Would we need a transition period where PHPCR still has the method (with
> @deprecated) that acts like a proxy to the Utils?

no, as implementations must rely on a specific version of phpcr anyways.
(usually its interface changes and those break the jackalopes)

> Not 100% sure about the converting to non-static. I usually try to avoid
> static methods as much as possible, but for Util functions it usually
> makes some sense.

it would make it easier for implementations to extend it and fix things
than if the call is hardcoded everywhere. and jackalope-doctrine-dbal
could change the implementation jackalope core is using, if it ever
needs to.

cheers,david

[Lukas Kahwe Smith]

On Apr 26, 2013, at 11:03 , David Buchmann <da...@liip.ch> wrote:

>> I think moving it to Utils makes sense.

+1 as well

regards,
Lukas Kahwe Smith
sm...@pooteeweet.org