Package proposal: Manipulator

[Виталий Степаненко]

Hi!
I wrote a small package (300+ LOC) to manipulate php objects (mass-assignment and extracting values considering autodetecting setters & getters, support of property-paths ('obj.someProperty.propertyOfProperty') and arrays).
It can be useful for working with objects of unknown type.
This package is passioned by symfony/property-access but it's much simpler (propcedural style, no OOD overengineering) and faster (I avoided usage of reflection).

See more details in repository, all documentation included: https://github.com/Nayjest/manipulator

[Woody Gilk]

Thanks for submitting this. Personally I wouldn't get a lot of use out of this package, because I tend to use immutable value objects with private properties, which this wouldn't help me with.

I'm also not entirely clear what the use case of a package like this is, as it seems like it would obfuscate the code. For example:

$value = mp\getValue($object, 'foo');

Feels a lot less obvious than:

$value = $object->foo;

What scenarios do you see your package being useful in?

--
Woody Gilk
http://about.me/shadowhand

--
You received this message because you are subscribed to the Google Groups "thephpleague" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague...@googlegroups.com.
To post to this group, send email to thephp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/ed2be225-8ff8-4794-9526-fd874cbaef0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ben Corlett]

Hey there,

I would second Woody on this, typically I would always know what methods are available on the objects I deal with and I typically use immutable VOs as well.

You’ve implemented your concept quote well, I am curious to see a few use-cases for the package where it makes more sense than dealing with objects directly?

Thanks!

Ben Corlett
Director
P: 02 4970 2244	M: 0438 732 218
A: 11/1 Reliance Dr, Tuggerah NSW 2259

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/CAGOJM6KbP7isskk1NXh9zr2b5crT%3DQOOwCZ5YrHD8O8EPcbi%2BQ%40mail.gmail.com.

[Виталий Степаненко]

Hi Woody,

Hi Ben,

Obviously this package is not suitable when you deal with single properties of concrete class instances.

It's useful for creating general-purpose code, i. e. code that will deal with any unknown objects or if you need mass-operations.

Few use-cases where manipulator can be handy:

Use-case 1: General purpose decorators, proxy objects, wrappers, data structures, etc

I will list few concrete examples to clarify what I mean:

 * Decorator that will sanitize values received from or written to decorated object to protect from XSS, SQL Injections, etc.

 * State monad implementation (JQuery-like) or collection that deals with properties of stored elements ( $collection->filterByProperty('role', 'Admin')->findByProperty('company.name', 'eBay'), )

Use-case 2: Mass-operations

* Example 2.1: Configuring objects. 

You have class with many setters and its configuration, you can just call mp\setValues($myObject, $config) to configure it. Or even instantiate and configure,  $inst = mp\instantiate($config['class'], $config['constructorArguments']); mp\setValues($inst, $config);

* Example 2.2: Data Export / Import / Serialization / API's. 

You need export data from object or you need to serialize object that can't be serialized using standard way because of closures & resources inside.

$values = mp\getValues($target, mp\getWritable($target));

// then filter and export

// or apply to object again

mp\setValues($anotherInstance, $values);

Use-case 3: You decided to implement your own var_dump or another kind of UI component that can display any object or even form to edit it.

It can be useful for those who already use symfony property-access. Manipulator will be faster because there is no Reflection usage and simplify code (IMHO: using factory to create property-access instance to read some property looks little bit overcomplicated for me). I want to note here that authors of symfony definitely had reasons to include property-access to symfony with their own use-cases.

In my work I used it for fast implementation of API's and in following packages:

- collections -- to deal with properties of collection elements

- builder -- for instantiating and initializing objects using configurations

- data grids --  for extracting fields from data rows that format can vary becouse package supports Laravel and Symfony models / query builders and raw arrays as data sources (it's possible to specify field name 'blog_post.author.company.name' for column and it will work for any data source, symfony property access was not suitable there because it has different syntax for accessing array elements and properties)

[Ben Corlett]

Hiya Vitalii,

Sorry I haven’t got back in a while on this, I’m revising it now.

Thank you for providing these examples, but I’m still struggling to see where I would ever use this over interacting with objects directly. I’m open to the others opting in for this, I personally feel it’s not something I would deal with or too much of a niche.

Woody?

Ben Corlett
Director
P: 02 4970 2244	M: 0438 732 218
A: 11/1 Reliance Dr, Tuggerah NSW 2259

--
You received this message because you are subscribed to the Google Groups "thephpleague" group.
To unsubscribe from this group and stop receiving emails from it, send an email to thephpleague...@googlegroups.com.
To post to this group, send email to thephp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/b5133d19-301d-4527-abfc-1c5265deb174%40googlegroups.com.

[Vitalii Stepanenko]

Hi!
* It can look too niche because every of its functions is very small and usually people just create own therefore it's hard to see usage. Need of this can be usually seen on refactoring step in concrete cases, but again it's not obvious because its purpose is to simple and to blurred. It's a set of simple helpers for its own different purposes that actually are obvious, grouped into one library on principle that all of them are around manipulating php objects. Any framework has lots of helpers like this, but usually nobody concentrates on them because they not solves tasks of framework, they solves issues that appears when creating framework.

For example, currently I work on framework-agnostic code therefore
1. I can't use framework helpers
2. If I create package with 1000 lines of code, I don't want to require a lot of heavy packages. For this reason I prefer my own https://github.com/Nayjest/StrCaseConverter/blob/master/src/Str.php over https://github.com/danielstjules/Stringy that has 2k+ LOC & dependencies from Symfony. But Stringy still is great for projects bigger than 1k LOC that requires more string functions.

This package is a try to find a balance between heavy packages whose monolithic structure dont allows to use its parts cheaply and micropackage madness typical now for NPM & Node.JS (example: https://www.npmjs.com/package/left-pad)

Anyway, please do not think that I'm furiously trying to convince you to take the package. This conversation is important to me in sense of understanding possibilities of code reusage, code structuring and community requirements to the code.

среда, 27 апреля 2016 г., 8:43:59 UTC+3 пользователь Ben Corlett написал:

[Woody Gilk]

Ben,

I agree with you. I feel like the need for this package is pretty niche, as a lot of the functionality is really to work around code that doesn't follow PSR-2 standards. In my personal experience, there isn't a lot of work with "objects of unknown types".

That said, I think the project is useful for those that need it, so I hope you continue to maintain it, Vitaliy!

--
Woody Gilk
http://about.me/shadowhand

To view this discussion on the web visit https://groups.google.com/d/msgid/thephpleague/77293909-9430-4E98-8395-F3C7F6CD51F5%40webcomm.io.