You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by sebb <se...@gmail.com> on 2010/09/30 03:46:55 UTC
[IO] Tailer API
Just wondering if the Tailer API could be simplified by performing the
thread start within the class?
Is it ever going to be useful to have direct access to tailer thread?
I suspect not, as the Listener should provide sufficient access.
It's not safe to start a thread in the constructor (unless the ctor is
final), but one could use static factory methods instead.
So instead of:
TailerListener listener = ...
Tailer tailer = new Tailer(file, listener, delay);
Thread thread = new Thread(tailer);
thread.start();
...
tailer.stop()
one would do something like:
TailerListener listener = ...
Tailer tailer = Tailer.createTailer(file, listener, delay);
...
tailer.stop()
This simplifies the API, and allows the class to force the thread to
be a daemon thread. It also stops the caller from messing with the
thread.
WDYT?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Tailer API
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Sep 30, 2010 at 11:25 AM, Niall Pemberton
<ni...@gmail.com> wrote:
>
> But keeping it simple here means leaving out any thread stuff and
> leaving it as a simple Runnable implementation. The more you include
> and hide, the more you reduce flexibility.
>
+1! What's with this obsession over holding the user's hand and
trying to make it absolutely impossible to do something stupid? The
more you try to protect them, the more you limit them.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Tailer API
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Sep 30, 2010 at 4:11 PM, sebb <se...@gmail.com> wrote:
> On 30 September 2010 12:06, James Carman <ja...@carmanconsulting.com> wrote:
>> On Thu, Sep 30, 2010 at 7:01 AM, sebb <se...@gmail.com> wrote:
>>>
>>> OK.
>>>
>>> So how about allowing the user to pass in an Executor when creating
>>> the instance?
>>> Would that be sufficient?
>>>
>>
>> KISS. Why add complexity here if it's not needed? Leaving it as a
>> Runnable allows the user to choose how to run it.
>
> I'm am trying to KIS for the user.
>
> The more internal implementation details are exposed, the harder it is
> to make any changes later.
But keeping it simple here means leaving out any thread stuff and
leaving it as a simple Runnable implementation. The more you include
and hide, the more you reduce flexibility.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Tailer API
Posted by sebb <se...@gmail.com>.
On 30 September 2010 12:06, James Carman <ja...@carmanconsulting.com> wrote:
> On Thu, Sep 30, 2010 at 7:01 AM, sebb <se...@gmail.com> wrote:
>>
>> OK.
>>
>> So how about allowing the user to pass in an Executor when creating
>> the instance?
>> Would that be sufficient?
>>
>
> KISS. Why add complexity here if it's not needed? Leaving it as a
> Runnable allows the user to choose how to run it.
I'm am trying to KIS for the user.
The more internal implementation details are exposed, the harder it is
to make any changes later.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Tailer API
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Sep 30, 2010 at 12:06 PM, James Carman
<ja...@carmanconsulting.com> wrote:
> On Thu, Sep 30, 2010 at 7:01 AM, sebb <se...@gmail.com> wrote:
>>
>> OK.
>>
>> So how about allowing the user to pass in an Executor when creating
>> the instance?
>> Would that be sufficient?
>>
>
> KISS. Why add complexity here if it's not needed? Leaving it as a
> Runnable allows the user to choose how to run it.
+1
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Tailer API
Posted by James Carman <ja...@carmanconsulting.com>.
On Thu, Sep 30, 2010 at 7:01 AM, sebb <se...@gmail.com> wrote:
>
> OK.
>
> So how about allowing the user to pass in an Executor when creating
> the instance?
> Would that be sufficient?
>
KISS. Why add complexity here if it's not needed? Leaving it as a
Runnable allows the user to choose how to run it.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Tailer API
Posted by sebb <se...@gmail.com>.
On 30 September 2010 06:39, Julien Aymé <ju...@gmail.com> wrote:
> 2010/9/30 sebb <se...@gmail.com>:
>> On 30 September 2010 02:58, Niall Pemberton <ni...@gmail.com> wrote:
>>> On Thu, Sep 30, 2010 at 2:46 AM, sebb <se...@gmail.com> wrote:
>>>> Just wondering if the Tailer API could be simplified by performing the
>>>> thread start within the class?
>>>> Is it ever going to be useful to have direct access to tailer thread?
>>>> I suspect not, as the Listener should provide sufficient access.
>>>>
>>>> It's not safe to start a thread in the constructor (unless the ctor is
>>>> final), but one could use static factory methods instead.
>>>>
>>>> So instead of:
>>>>
>>>> TailerListener listener = ...
>>>> Tailer tailer = new Tailer(file, listener, delay);
>>>> Thread thread = new Thread(tailer);
>>>> thread.start();
>>>> ...
>>>> tailer.stop()
>>>>
>>>> one would do something like:
>>>>
>>>> TailerListener listener = ...
>>>> Tailer tailer = Tailer.createTailer(file, listener, delay);
>>>> ...
>>>> tailer.stop()
>>>>
>>>> This simplifies the API, and allows the class to force the thread to
>>>> be a daemon thread. It also stops the caller from messing with the
>>>> thread.
>>>>
>>>> WDYT?
>>>
>>> There are five different Thread constructors that take a Runnable and
>>> a bunch of other methods that someone might want to use. I don't have
>>> a problem providing a convenience static method - but it only saves
>>> two lines of code - as long as they can construct one manually with or
>>> without a Thread if they want to.
>>
>> But what is the use case for having access to the created thread?
>> Seems to me it would be a lot safer if the thread were private to the class.
>
> The use case is that someone may want to use an Executor instead of a
> dedicated Thread to run background tasks such as Tailer, at least I
> do. I have no problem with providing a convenient static method, as
> Niall suggested, but I would like to keep the Tailer as a Runnable
> with no embedded thread if possible.
OK.
So how about allowing the user to pass in an Executor when creating
the instance?
Would that be sufficient?
> HTH,
> Julien
>
>>
>> It would still be possible to use the code without a thread by
>> exposing the method that loops over the file, and using the
>> constructor instead.
>> For example with the current code one could do something like:
>>
>> TailerListener listener = ...
>> Tailer tailer = new Tailer(file, listener, delay);
>> tailer.run()
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Tailer API
Posted by Julien Aymé <ju...@gmail.com>.
2010/9/30 sebb <se...@gmail.com>:
> On 30 September 2010 02:58, Niall Pemberton <ni...@gmail.com> wrote:
>> On Thu, Sep 30, 2010 at 2:46 AM, sebb <se...@gmail.com> wrote:
>>> Just wondering if the Tailer API could be simplified by performing the
>>> thread start within the class?
>>> Is it ever going to be useful to have direct access to tailer thread?
>>> I suspect not, as the Listener should provide sufficient access.
>>>
>>> It's not safe to start a thread in the constructor (unless the ctor is
>>> final), but one could use static factory methods instead.
>>>
>>> So instead of:
>>>
>>> TailerListener listener = ...
>>> Tailer tailer = new Tailer(file, listener, delay);
>>> Thread thread = new Thread(tailer);
>>> thread.start();
>>> ...
>>> tailer.stop()
>>>
>>> one would do something like:
>>>
>>> TailerListener listener = ...
>>> Tailer tailer = Tailer.createTailer(file, listener, delay);
>>> ...
>>> tailer.stop()
>>>
>>> This simplifies the API, and allows the class to force the thread to
>>> be a daemon thread. It also stops the caller from messing with the
>>> thread.
>>>
>>> WDYT?
>>
>> There are five different Thread constructors that take a Runnable and
>> a bunch of other methods that someone might want to use. I don't have
>> a problem providing a convenience static method - but it only saves
>> two lines of code - as long as they can construct one manually with or
>> without a Thread if they want to.
>
> But what is the use case for having access to the created thread?
> Seems to me it would be a lot safer if the thread were private to the class.
The use case is that someone may want to use an Executor instead of a
dedicated Thread to run background tasks such as Tailer, at least I
do. I have no problem with providing a convenient static method, as
Niall suggested, but I would like to keep the Tailer as a Runnable
with no embedded thread if possible.
HTH,
Julien
>
> It would still be possible to use the code without a thread by
> exposing the method that loops over the file, and using the
> constructor instead.
> For example with the current code one could do something like:
>
> TailerListener listener = ...
> Tailer tailer = new Tailer(file, listener, delay);
> tailer.run()
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Tailer API
Posted by sebb <se...@gmail.com>.
On 30 September 2010 02:58, Niall Pemberton <ni...@gmail.com> wrote:
> On Thu, Sep 30, 2010 at 2:46 AM, sebb <se...@gmail.com> wrote:
>> Just wondering if the Tailer API could be simplified by performing the
>> thread start within the class?
>> Is it ever going to be useful to have direct access to tailer thread?
>> I suspect not, as the Listener should provide sufficient access.
>>
>> It's not safe to start a thread in the constructor (unless the ctor is
>> final), but one could use static factory methods instead.
>>
>> So instead of:
>>
>> TailerListener listener = ...
>> Tailer tailer = new Tailer(file, listener, delay);
>> Thread thread = new Thread(tailer);
>> thread.start();
>> ...
>> tailer.stop()
>>
>> one would do something like:
>>
>> TailerListener listener = ...
>> Tailer tailer = Tailer.createTailer(file, listener, delay);
>> ...
>> tailer.stop()
>>
>> This simplifies the API, and allows the class to force the thread to
>> be a daemon thread. It also stops the caller from messing with the
>> thread.
>>
>> WDYT?
>
> There are five different Thread constructors that take a Runnable and
> a bunch of other methods that someone might want to use. I don't have
> a problem providing a convenience static method - but it only saves
> two lines of code - as long as they can construct one manually with or
> without a Thread if they want to.
But what is the use case for having access to the created thread?
Seems to me it would be a lot safer if the thread were private to the class.
It would still be possible to use the code without a thread by
exposing the method that loops over the file, and using the
constructor instead.
For example with the current code one could do something like:
TailerListener listener = ...
Tailer tailer = new Tailer(file, listener, delay);
tailer.run()
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [IO] Tailer API
Posted by Niall Pemberton <ni...@gmail.com>.
On Thu, Sep 30, 2010 at 2:46 AM, sebb <se...@gmail.com> wrote:
> Just wondering if the Tailer API could be simplified by performing the
> thread start within the class?
> Is it ever going to be useful to have direct access to tailer thread?
> I suspect not, as the Listener should provide sufficient access.
>
> It's not safe to start a thread in the constructor (unless the ctor is
> final), but one could use static factory methods instead.
>
> So instead of:
>
> TailerListener listener = ...
> Tailer tailer = new Tailer(file, listener, delay);
> Thread thread = new Thread(tailer);
> thread.start();
> ...
> tailer.stop()
>
> one would do something like:
>
> TailerListener listener = ...
> Tailer tailer = Tailer.createTailer(file, listener, delay);
> ...
> tailer.stop()
>
> This simplifies the API, and allows the class to force the thread to
> be a daemon thread. It also stops the caller from messing with the
> thread.
>
> WDYT?
There are five different Thread constructors that take a Runnable and
a bunch of other methods that someone might want to use. I don't have
a problem providing a convenience static method - but it only saves
two lines of code - as long as they can construct one manually with or
without a Thread if they want to.
Niall
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org