[Text] Consider making the project "multimodule"

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

[Text] Consider making the project "multimodule"

Gilles Sadowski
Hi.

I think that it would be worth modularizing the [Text] component.
I only had quick glances, but it seems that some codes are more
generic than others (that e.g. focused on HTML entities).

The scope of [Text] could obviously encompass functionality for
which there isn't any code yet. An example is currently the subject
of a thread with subject:
  [Numbers] Parsing and formatting classes

Hence, I think that it would make sense that [Text] is prepared
to provide new utilities that handle domains not initially foreseen,
while mitigating the risk of becoming a huge monolithic component.


Thanks,
Gilles


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Text] Consider making the project "multimodule"

Rob Tompkins

> On Jan 30, 2017, at 8:46 AM, Gilles <[hidden email]> wrote:
>
> Hi.
>
> I think that it would be worth modularizing the [Text] component.
> I only had quick glances, but it seems that some codes are more
> generic than others (that e.g. focused on HTML entities).

I lean towards going with a single module out of simplicity, but I’m open to the idea. I’m curious with what others have to say here.

-Rob

>
> The scope of [Text] could obviously encompass functionality for
> which there isn't any code yet. An example is currently the subject
> of a thread with subject:
> [Numbers] Parsing and formatting classes
>
> Hence, I think that it would make sense that [Text] is prepared
> to provide new utilities that handle domains not initially foreseen,
> while mitigating the risk of becoming a huge monolithic component.
>
>
> Thanks,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Text] Consider making the project "multimodule"

garydgregory
On Jan 30, 2017 6:16 AM, "Rob Tompkins" <[hidden email]> wrote:


> On Jan 30, 2017, at 8:46 AM, Gilles <[hidden email]> wrote:
>
> Hi.
>
> I think that it would be worth modularizing the [Text] component.
> I only had quick glances, but it seems that some codes are more
> generic than others (that e.g. focused on HTML entities).

I lean towards going with a single module out of simplicity, but I’m open
to the idea. I’m curious with what others have to say here.

-Rob

>
> The scope of [Text] could obviously encompass functionality for
> which there isn't any code yet. An example is currently the subject
> of a thread with subject:
> [Numbers] Parsing and formatting classes
>
> Hence, I think that it would make sense that [Text] is prepared
> to provide new utilities that handle domains not initially foreseen,
> while mitigating the risk of becoming a huge monolithic component.


Single module seems good for now.

Gary

>
>
> Thanks,
> Gilles
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [Text] Consider making the project "multimodule"

Emmanuel Bourg-3
In reply to this post by Rob Tompkins
Le 30/01/2017 à 15:16, Rob Tompkins a écrit :

> I lean towards going with a single module out of simplicity

+1

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

[Text] New feature: Parsing and formatting numbers (Was: Consider making the project "multimodule")

Gilles Sadowski
In reply to this post by Gilles Sadowski
On Mon, 30 Jan 2017 14:46:25 +0100, Gilles wrote:

> Hi.
>
> I think that it would be worth modularizing the [Text] component.
> I only had quick glances, but it seems that some codes are more
> generic than others (that e.g. focused on HTML entities).
>
> The scope of [Text] could obviously encompass functionality for
> which there isn't any code yet. An example is currently the subject
> of a thread with subject:
>  [Numbers] Parsing and formatting classes

Would [Text] be welcoming utilities to handle I/O of fractions,
complex numbers, matrices, and so on?

Gilles

>
> [...]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Text] New feature: Parsing and formatting numbers (Was: Consider making the project "multimodule")

Rob Tompkins


> On Jan 30, 2017, at 7:47 PM, Gilles <[hidden email]> wrote:
>
>> On Mon, 30 Jan 2017 14:46:25 +0100, Gilles wrote:
>> Hi.
>>
>> I think that it would be worth modularizing the [Text] component.
>> I only had quick glances, but it seems that some codes are more
>> generic than others (that e.g. focused on HTML entities).
>>
>> The scope of [Text] could obviously encompass functionality for
>> which there isn't any code yet. An example is currently the subject
>> of a thread with subject:
>> [Numbers] Parsing and formatting classes
>
> Would [Text] be welcoming utilities to handle I/O of fractions,
> complex numbers, matrices, and so on?
>

I could see an argument for [text], [lang], or [numbers]. But it definitely feels somewhere in the middle of [text] and [numbers]. Either way I'd be happy to work on that. It seems interesting.

-Rob

> Gilles
>
>>
>> [...]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Text] Consider making the project "multimodule"

Stian Soiland-Reyes
In reply to this post by Emmanuel Bourg-3
Modules of Text would make sense if we get larger differences of
dependencies; if it is just different functionality, subpackages within a
single module would be better.

On 30 Jan 2017 5:53 pm, "Emmanuel Bourg" <[hidden email]> wrote:

> Le 30/01/2017 à 15:16, Rob Tompkins a écrit :
>
> > I lean towards going with a single module out of simplicity
>
> +1
>
> Emmanuel Bourg
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [Text] Consider making the project "multimodule"

Gilles Sadowski
On Thu, 2 Feb 2017 09:41:59 +0000, Stian Soiland-Reyes wrote:
> Modules of Text would make sense if we get larger differences of
> dependencies; if it is just different functionality, subpackages
> within a
> single module would be better.

Indeed, the proposal was with an eye towards differing dependency
requirements:
  * formatting/parsing of "Complex" would depend on the module
    "commons-numbers-complex"
  * formatting/parsing of "Fraction" would depend on the module
    "commons-numbers-fraction"
while none of the functionality that exists today in [Text] needs
to pull those dependencies.

Gilles

>
> On 30 Jan 2017 5:53 pm, "Emmanuel Bourg" <[hidden email]> wrote:
>
>> Le 30/01/2017 à 15:16, Rob Tompkins a écrit :
>>
>> > I lean towards going with a single module out of simplicity
>>
>> +1
>>
>> Emmanuel Bourg
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]