Skip to content

Conversation

doenietzomoeilijk
Copy link
Contributor

The old Number\Ordinal is no longer directly responsible for the ordinal string
generation. Instead, it'll use a dynamically included closure for that. Closures
for English and Dutch are included.

Intended as Proof of Concept, but I can see this working.

Relates to #39

The old Number\Ordinal is no longer directly responsible for the ordinal string
generation. Instead, it'll use a dynamically included closure for that. Closures
for English and Dutch are included.
@norberttech
Copy link
Member

@doenietzomoeilijk that looks good, I would just suggest to replace callbacks with Strategy Pattern
Each strategy can be registered in builder or even better resolver under specific locale and used according to passed value.

@doenietzomoeilijk
Copy link
Contributor Author

@norzechowicz I did start out thinking about doing the localized parts in objects, but decided against it, as it involved a whole lot more code and i couldn't think of a way to have it all work automatically.

I might come up with an idea, later this weekend.

@norberttech
Copy link
Member

👍

@doenietzomoeilijk
Copy link
Contributor Author

@norzechowicz How about this? I'll still need to refactor the actual call back to something involving __toString() to keep BC, but other than that this should be less hacky than the closures.

(Real life happened for a week, sorry for the silence on my end).

norberttech pushed a commit that referenced this pull request Nov 19, 2015
Refactor Number into separate languages
@norberttech norberttech merged commit 3eb227e into coduo:master Nov 19, 2015
@norberttech
Copy link
Member

@doenietzomoeilijk thanks and orry for late response 🍻

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants