BugFix in DataObject::__construct()

[claudio-dalicandro]

BugFix in \OpenCloud\ObjectStore\Resource\DataObject::__construct()

[claudio-dalicandro]

You were going to call $this->populate($data) only if $data['subdir'] is not set, or have I misunderstood?

[jamiehannaford]

Yes, because pseudo-directory structures only contain two attributes. Both of which are populated using the methods above. For normal objects, you need to call populate so that the entire object is correctly stocked.

[jamiehannaford]

@claudio-dalicandro Could you outline what the bug is and how your code fixes it?

[claudio-dalicandro]

1. If $data is null (as default...) empty($data->subdir) produces an error
2. If I understand it, $data is an array, then $data->subDir is wrong
3. $this->setName() not existed
4. $this->setDirectory() not existed
5. According to your documentation (https://github.com/rackspace/php-opencloud/blob/master/docs/quickref.md#create-a-new-object-in-a-container), the DataObject::$name must be set when creating a new object, but the property is private and has no setter

[claudio-dalicandro]

Ok, I've seen, you can not know what is $date... It could be an object or an array...

[jamiehannaford]

@claudio-dalicandro To answer your points:

1. Really? It doesn't on mine. What version of PHP are you running?
2. $data should be passed through either as a string (i.e. the object name), or as an object (if it's instantiated inside a Collection). If you look at the populate method, you can see how it handles mixed types.
3. These properties are set using overloading. To reduce the amount of superfluous setter/getters, resource models with private properties can be mutated and accessed through overloaded methods. So, for example, if you have this model:

class Person
{
    private $name;
    private $age;
}

although there are no concrete methods for accessing/mutating these properties, this will work:

$person = new Person();
$person->setName('Jamie');
echo $person->getName(); // Jamie
echo $person->getAge();  // NULL

echo $person->getHeight(); // throws RuntimeException "no method"

Concrete setter/getters are only used for specific pieces of business logic.

[claudio-dalicandro]

My PHP version:

$ php -v
PHP 5.4.17-1~precise+1 (cli) (built: Jul 17 2013 18:14:06)

Test

<?php

// test.php

class test {
    private $a;
    private $b;
}

$test = new test();
$test->setA('testing');
echo $test->getA();

error...

$ php test.php
PHP Fatal error:  Call to undefined method test::setA() in ./test.php on line 8
PHP Stack trace:
PHP   1. {main}() ./test.php:0

[jamiehannaford]

@claudio-dalicandro Sorry, you're right. This functionality only happens when the visibility of a property is private not protected. I'll add in these two setter methods tomorrow and get a new release out. Thanks for the heads up!

[claudio-dalicandro]

@jamiehannaford I'm sorry, but I think it does not work right: AFAIK overloading works if implements magic methods __set() and __get() but:

1. only at points where the property would not be accessible (and therefore not within the methods of the same class)
2. however, accessing the property that isn't directly accessible, so not $obj->setA('test'), but instead $obj->a = 'test'

Surely I could be wrong, I never use the overload because

they are actually really dangerous. They make APIs unclear, auto-completion impossible and most importantly they are slow. The use case for them was to hack PHP to do things which it didn’t want to. And it worked. But made bad things happen.

-- Juozas "Joe" Kaziukėnas

[jamiehannaford]

@claudio-dalicandro I'm not sure I understand your two points... Please see my response to #215.

I'm not familiar with Juozas Kaziukėnas's blog entry where he warns about method overloading, but I'm always somewhat skeptical when people make generalized statements like "doing x is bad". There are almost always certain use cases where implementing a particular language feature is useful. Method overloading is one of them, at least for the current state of the SDK. I'd love to have concrete methods for every resource model, but we're not there yet. It's a gradual compromise between understanding what you want, what's realistically possible for the next release, and what you need to do to make things as backwards possible as possible.

[jamiehannaford]

@claudio-dalicandro Methods have been added to DataObject allowing for getting/setting the name and directory. Thanks again.