Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

number to word conception #1

Open
joubertredrat opened this issue May 6, 2016 · 9 comments
Open

number to word conception #1

joubertredrat opened this issue May 6, 2016 · 9 comments

Comments

@joubertredrat
Copy link

joubertredrat commented May 6, 2016

Hi guys,

This is a first conception about translate numbers to words but I have more questions.

  • Tell me if you like this conception 👍
  • This will "write" only to pt-br or another languages too?
  • Script will consider only int type or string number type with or without point separators?

If I have more questions I will put here. Let's talk.

@lucasmezencio
Copy link
Contributor

It will be for ANY language in the world. Keep it in mind: ANY. 😃

@luizpedone
Copy link

Hey guys! Looking forward to this project. It seems really promising.

Just a few thoughts about it:

  • I think it could start simple. Maybe it's smart to think about a single language before tacking the multi-language problem.
  • I think it's fundamental that this project contains unit tests.
  • I think building this project using TDD will help a lot the structure of the project and it's maintainability.

If I can help somehow, please ping me on Slack or here. I'll be glad to help.

@luizpedone
Copy link

@joubertredrat Just saw your gist and have some suggestions:

  • I think we should have the language structure on a configuration file. It might be something like an array with the language config, something similar of what Laravel does. From that structure we'll get the structure and words needed to build the output.
  • Did you had any reason to not write that implementation on this repository? I think it'll be cool to do it here and make a PR, so we can discuss these issues pointing directly to the code and we could test it locally to ensure it's working.
  • Did you have unit tests in mind? I missed it on your gist file.

@luizpedone
Copy link

One more thing, my suggestion about the package usage interface:

<?php

interface NumberToWord {
    public function __construct(Language $language);
    public function getValueInWords($valueInNumbers);
    public function getValueInNumbers($valueInWords);
}

// usage
$value = new NumberToWord(new PortugueseLanguage());
$value->getValueInWords(299); // will output duzentos e noventa e nove
$value->getValueInNumbers('duzentos e noventa e nove'); // will output 299

@pedrochaves
Copy link

The question actually is how are we going to structure this file to be generic for every language, since every language has their own specificities.

Example for the number 1700:

  • In portuguese, it's Mil e setecentos
  • In french it's Mille sept cent
  • In english it's One thousand seven hundred or Seventeen hundred

The problem here is:

  • In portuguese the number is broken down into 1000 + 700
  • In french and the first english version it is 1000 + (7 * 100)
  • The short version in english is 17 * 100

See what I mean? Each language structures numbers in a totally different ways and some even have more than one way to do this. How to structure this file? Am I overcomplicating things?

@luizpedone
Copy link

@pedrochaves I agree with you that each language has it's own structure so it's hard to create a generic code to all. That's why I proposed a Language interface in which each language will have it's own implementation of the rules required to process it. It's also simplifies how to start the project: we can start with Portuguese or English, make it work and in the future focus on new languages. Doing that using the interface, we ensure that the NumberToWord class calls exact method for the required language.

@luizpedone
Copy link

Guys, just made a commit with the basic structure that I said previously. I think there's several flaws on it, but it's a start.

Do you guys have any idea on how to improve it? I'm quite skeptical about the NumberToWord class. It's a wrapper to the LanguageInterface, but I'm not sure if we need it.

Anyway, it's just a proposal. If you guys think it's good, we can move forward with it. If there's some better approaches to it, feel free to move on another direction.

@pedrochaves
Copy link

pedrochaves commented May 8, 2016

@luizpedone I thought of some alternatives (I also changed the method names, see what you guys think):

  • The one you implemented, with dependency inversion;
  • As a factory
$translator = NumberToWordTranslatorFactory::createForLanguage(Language::PORTUGUESE);
$word = $translator->toWord(299);
$number $translator->toNumber('duzentos');
  • Loading languages on the same object
$translator = new NumberToWordTranslator();
// This would be the __call, setting a private attribute
$translator->loadPortuguese(); 
// Or another option (in this case, the parameter can be passed on constructor)
$translator->load(Language::PORTUGUESE);

$word = $translator->toWord(299);
$number = $translator->toNumber('duzentos');
  • Using __get
$translator = new NumberToWordTranslator();

// This would have to be a singleton to avoid creating objects on every call
$word = $translator->portuguese->toWord(299);
$number = $translator->portuguese->toNumber('duzentos');

(enums would be awesome here :()

@joubertredrat
Copy link
Author

Hi guys,

For consistent language selector, we need to use RFC 3066 to set language, as in here.

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

No branches or pull requests

4 participants