Jump to content


  • Content count

  • Joined

  • Last visited

  • Days Won


ignace last won the day on May 14

ignace had the most liked content!

Community Reputation

196 Excellent

About ignace

  • Rank
    Prolific Member
  • Birthday 09/05/1986

Profile Information

  1. ignace

    Do i have to pay tax if teach on the web

    If you have a monetary income in any officially recognized currency*, you need to pay tax! It's that simple, really. Now it's possible that certain income is exempt from tax, for example, a yearly turn-over less then 5.000 individually, or 25.000 as a business. That's the current law in Belgium. I am not an accountant, and I am unfamiliar with tax regulations in Australia. If you have a business, it's recommended to have an accountant, he'll advise you on the best approach, and keep your taxes in check. *So anything not monetary, or any unofficial currency, would be tax-free. Get paid in litecoin?
  2. ignace

    New Guru: maxxd

    Nope, they don't. At least not in my case, others may have had better luck. I was only joking when I said that. I am already happy if I get a thumbs up on my answers.
  3. ignace

    Composition over inheritance examples

    Admin seems more like a privilege/role, so I would make that a field of User. Then your User and Person. I get what you are saying, and I have this in my system. I would have a Person object with no reference to a User. And let the User reference Person. Thus decoupling my application from the auth layer. <?php class User { const ROLE_SYSTEM = 'role_system'; const ROLE_ADMIN = 'role_admin'; /** * @var string[] */ private $roles = [ ]; /** * @var Person|null */ private $person; } For system accounts, the Person reference would be NULL as it's not required and it's role would be ROLE_SYSTEM.
  4. ignace

    Should mappers digest objects?

    And after you started using the power sander, how often have you done it by hand since? And if given the chance to do it by hand, would you still do it? Regardless of the fact that these are apples and oranges. If done by hand or machine delivers about the same end-product. Regardless with which you started or ended. You can start by hand, go to the machine, and finish by hand. Also the work still has to be done, to get the final product. This is not the case in software development. You would basically pick up an already sanded object of any length and any given size in an infinite supply.
  5. ignace

    Should mappers digest objects?

    Events are a good way to extend your code without adding unnecessary dependencies. A ghost copy is a class with only it's ID filled in. Personally I avoid writing things that have been written before and rather build upon them. In the long run of an application you get burned by the "not invented here" syndrome. I have seen it over and over, and over again.
  6. ignace

    Should mappers digest objects?

    What requinix said, and to reduce unnecessary: querying, hydrating, etc.. for what is essentially throwing something into the bin. And it still allows your mapper to fire off any associated events, if there would be any. Another option would be to use a ghost copy, and drop the deleteOneById. But that depends on how you architect your software. Since a DELETE is the opposite of a SELECT. You can create any "query" methods for it: deleteAllByCompanyName(string $companyName); Internally they do the same thing as with the deleteOneById. They query and store any ID's scheduled for deletion. So that any future find's would return NULL even before the database is synchronised. Avoid any createFromArray or updateFromArray methods though, use the find methods instead.
  7. ignace

    Should mappers digest objects?

    For a Data Mapper this is mixed. Since your mapper maps from and to the database. You would need to be able to use several types of input to get what you need. <?php interface UserMapper { function findOneById(int $id): ?User; function findAllById(array $id): ?UserCollection; function findOneByUsernameAndEmail(string $username, string $email): ?User; function findAllRegisteredBetween(DateTimeInterface $start, DateTimeInterface $end): ?UserCollection; function findAllRecentlyRegistered(DateTimeInterface $currentDate): ?UserCollection; function create(User $user): void; function createAll(UserCollection $users): void; function update(User $user): void; function updateAll(UserCollection $users): void; function delete(User $user): void; function deleteAll(UserCollection $users): void; function deleteOneById(int $id): void; }
  8. ignace

    Collection classes

    And that's bad? Why? Ever seen classes implement nothing more than __invoke? Or a Command with only an execute() method. What about 2 methods? How many methods should in your opinion a class have?
  9. ignace

    Should properties with methods be public or private?

  10. ignace

    Should properties with methods be public or private?

    Properties are like your intestines, you don't want anyone else to touch them. Unless, perhaps for surgery (my architect mind is already modelling this, I'll spare you the details). Therefor they should always be private. If something does need access, they can use an interface you control. In certain cases you could opt to mirror methods instead of exposing the sub-object, but it's certainly not advisable to mirror the entire interface. In this case, just create a getter. But don't ever expose a public property, you are inviting bugs. PHP does not yet have the powers other OO languages have.
  11. ignace

    New Guru: maxxd

    Well, pretty much everyone on here has a "Donate to me!" button so go ahead and buy us all a round Congrats on the promotion!
  12. ignace

    Should entity properties be protected or public?

    Yes, preferably it should always be the responsibility of another class unless the domain warrants the use of JsonSerializable. For example, the object is stored/read from a JSON store.
  13. ignace

    Should entity properties be protected or public?

    No I am not, though it's a good thing to always start from final class, as it will make you think harder about your code. That said, I extend my entity classes every time there's a need. Protected properties and inheritance are two separate things anyway. A protected property is a "public" property in disguise, just think about that for a second. Why would a child have privileged access to "private" information? If there is a need to give privileged information to a child then you can still resort to a protected method. This will ensure the data remains encapsulated. Is available to the child as a sort of contract (guaranteed access to the data). And allows the parent to change properties anyway they want (eg from a string to an object).
  14. With that said, perhaps you don't want to expose all properties. In that case you can also resort to using a Visitor <?php interface NodeVisitor { function visitNode(Node $node); function visitCategory(CategoryNode $node); // ... } final class Node { function accept(NodeVisitor $nodeVisitor) { $nodeVisitor->vistNode($this); foreach ($this->categories as $category) { $nodeVistor->visitCategory($category); } } } $node->accept($myNodeVisitor); $json = $myNodeVisitor->getResult(); This is of course a little more difficult then using a simple serializer.
  15. Move the logic of serializing out of your entities. It does not belong there, nor should your properties be protected, they should be private. Only if absolutely necessary, can they be protected. And even then you can still create a protected getter/setter of some sort. I already posted how to do the serializing in your other thread. <?php interface NodeSerializer { function serialize(Node $node); function unserialize($input, Node $node); } With this you can create as many 'views' as you need.

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.