From: andijcr on
hi all
i have a byte stream that has to be decoded in a list of simple
containers - basically I do a translation from serial to parallel.
The implementation I'm using now has this form:

public class RawProtocol{

private long millis=/*some initialization procedure*/;
public RawProtocol(InputStream inputStream, OutputStream
outputStream){
this.bq=new LinkedBlockingQueue<Byte>();
this.is=inputStream;
this.os=outputStream;
}

public RawData getRawData() {
Byte temp;
do{
if((temp=bq.poll())!=null)
state=state.exec(temp);
else
return null;
}while(state!=Mlsm.START);
/*...
return a deserialized packet
... */
}

enum Mlsm{ //stands for my little state machine

START {
public Mlsm exec(byte time){
pushTime(time); //this byte represents a time and
should be treated in a way
return TIME_RED;
}
},
TIME_RED {
public Mlsm exec(byte value){
pushValue(value); //this is a value and should be
treated in another way
return VALUE_RED;
}
},
VALUE_RED {
public Mlsm exec(byte stop){
switch (stop){
case stopByte:
commit(); //the sequence (time - value) is well
formed and can be saved in a packet
return START;
default: return GARBAGE;
}
}
},
GARBAGE {
public Mlsm exec(byte grbg){
switch (grbg){
case stopByte: return START;
default: return this;
}
}
};

public abstract Mlsm exec(byte b);
}
}

the machine is activated through getRawData, which makes it perform a
complete cycle to produce a single packet of formatted data

the initial idea to use a state machine implemented as an inner class
was to:
- bring order in the code
- to take advantage of some time-dependent data (millis) managed by
the outer class RawProtocol (most important)

However enum is defined as static, and this disables access to the
fields of rawprotocol.
The main issue then is: how can I make a private field (not static) of
RawProtocol accessible (read at least) to Mlsm, in an elegant way and
java-esque way?

The main issue then is: how can I make a field private (not static)
RawProtocol accessible (for reading at least) to Mlsm, in an elegant
way and to objects?

The first ideas I had (but I would like to avoid) were to delegate to
the state machine only the definition of the sequence of operations,
implementing the same operations as methods of an instance of
RawProtocol;
Or convert `enum Mlsm` in an inner `class Mlsm` that acts as enum
(rewriting all the methods that would otherwise be handled
automatically by the compiler) except for the fact to be not static.

Or convert enum Mlsm in an inner class that acts as Mlsm enum (then
writing all the methods that would otherwise be handled automatically
by the compiler) except that it is not static.

other ideas - standard methodologies to resolve the issue?
From: Lew on
andijcr wrote:
> The main issue then is: how can I make a field private (not static)
> RawProtocol accessible (for reading at least) to Mlsm, in an elegant
> way and to objects?

Pass it as an argument to the enum 'exec' method.

--
Lew
From: Tom Anderson on
On Wed, 10 Feb 2010, andijcr wrote:

> i have a byte stream that has to be decoded in a list of simple
> containers - basically I do a translation from serial to parallel. The
> implementation I'm using now has this form:
>
> public class RawProtocol{
>
> private long millis=/*some initialization procedure*/;
> public RawProtocol(InputStream inputStream, OutputStream
> outputStream){
> this.bq=new LinkedBlockingQueue<Byte>();
> this.is=inputStream;
> this.os=outputStream;
> }
>
> public RawData getRawData() {
> Byte temp;
> do{
> if((temp=bq.poll())!=null)
> state=state.exec(temp);
> else
> return null;
> }while(state!=Mlsm.START);
> /*...
> return a deserialized packet
> ... */
> }
>
> enum Mlsm{ //stands for my little state machine
>
> START {
> public Mlsm exec(byte time){
> pushTime(time); //this byte represents a time and
> should be treated in a way
> return TIME_RED;
> }
> },
> TIME_RED {
> public Mlsm exec(byte value){
> pushValue(value); //this is a value and should be
> treated in another way
> return VALUE_RED;
> }
> },
> VALUE_RED {
> public Mlsm exec(byte stop){
> switch (stop){
> case stopByte:
> commit(); //the sequence (time - value) is well
> formed and can be saved in a packet
> return START;
> default: return GARBAGE;
> }
> }
> },
> GARBAGE {
> public Mlsm exec(byte grbg){
> switch (grbg){
> case stopByte: return START;
> default: return this;
> }
> }
> };
>
> public abstract Mlsm exec(byte b);
> }
> }
>
> the machine is activated through getRawData, which makes it perform a
> complete cycle to produce a single packet of formatted data
>
> the initial idea to use a state machine implemented as an inner class
> was to:
> - bring order in the code

Seriously? You think that's more ordered than:

DataInputStream in;
while (true) {
pushTime(in.readByte());
pushValue(in.readByte());
byte stop = in.readByte();
if (stop == stopByte) {
commit();
}
else {
while ((stop = in.readByte()) != stopByte);
}
}

?

If what you've posted is really what you're doing, and not a huge
simplification of what you're actually doing, then you've massively
overcomplicated this.

> - to take advantage of some time-dependent data (millis) managed by the
> outer class RawProtocol (most important)

I don't see why you couldn't do that with the above loop.

tom

--
It's rare that you're simply presented with a knob whose only two
positions are "Make History" and "Flee Your Glorious Destiny." --
Tycho Brahae
From: andijcr on
On 10 Feb, 20:02, Tom Anderson <t...(a)urchin.earth.li> wrote:
> On Wed, 10 Feb 2010, andijcr wrote:
> > i have a byte stream that has to be decoded in a list of simple
> > containers - basically I do a translation from serial to parallel. The
> > implementation I'm using now has this form:
>
> > public class RawProtocol{
>
> >    private long millis=/*some initialization procedure*/;
> >    public RawProtocol(InputStream inputStream, OutputStream
> > outputStream){
> >        this.bq=new LinkedBlockingQueue<Byte>();
> >        this.is=inputStream;
> >        this.os=outputStream;
> >    }
>
> >    public RawData getRawData() {
> >        Byte temp;
> >        do{
> >            if((temp=bq.poll())!=null)
> >            state=state.exec(temp);
> >            else
> >                return null;
> >        }while(state!=Mlsm.START);
> >        /*...
> >          return a deserialized packet
> >         ... */
> >    }
>
> >    enum Mlsm{        //stands for my little state machine
>
> >        START {
> >            public Mlsm exec(byte time){
> >                pushTime(time);  //this byte represents a time and
> > should be treated in a way
> >                return TIME_RED;
> >            }
> >        },
> >        TIME_RED {
> >            public Mlsm exec(byte value){
> >                pushValue(value);  //this is a value and should be
> > treated in another way
> >                return VALUE_RED;
> >            }
> >        },
> >        VALUE_RED {
> >            public Mlsm exec(byte stop){
> >                switch (stop){
> >                case stopByte:
> >                    commit();  //the sequence (time - value) is well
> > formed and can be saved in a packet
> >                    return START;
> >                default: return GARBAGE;
> >                }
> >            }
> >        },
> >        GARBAGE {
> >            public Mlsm exec(byte grbg){
> >                switch (grbg){
> >                case stopByte: return START;
> >                default: return this;
> >                }
> >            }
> >        };
>
> >        public abstract Mlsm exec(byte b);
> >    }
> > }
>
> > the machine is activated through getRawData, which makes it perform a
> > complete cycle to produce a single packet of formatted data
>
> > the initial idea to use a state machine implemented as an inner class
> > was to:
> > - bring order in the code
>
> Seriously? You think that's more ordered than:
>
> DataInputStream in;
> while (true) {
>         pushTime(in.readByte());
>         pushValue(in.readByte());
>         byte stop = in.readByte();
>         if (stop == stopByte) {
>                 commit();
>         }
>         else {
>                 while ((stop = in.readByte()) != stopByte);
>         }
>
> }
>
> ?
>
> If what you've posted is really what you're doing, and not a huge
> simplification of what you're actually doing, then you've massively
> overcomplicated this.
>
> > - to take advantage of some time-dependent data (millis) managed by the
> > outer class RawProtocol (most important)
>
> I don't see why you couldn't do that with the above loop.
>
> tom
>
> --
> It's rare that you're simply presented with a knob whose only two
> positions are "Make History" and "Flee Your Glorious Destiny." --
> Tycho Brahae

the snippet is a simplification of the real code, tough it is not so
much more complicated. Here i made the decision to use a simple
implementation of a state machine, instead of a sequence of methods,
for the elasticity i can obtain in the interpretation of the not-so-
stable underlying protocol.
From: Tom Anderson on
On Wed, 10 Feb 2010, andijcr wrote:

> On 10 Feb, 20:02, Tom Anderson <t...(a)urchin.earth.li> wrote:
>> On Wed, 10 Feb 2010, andijcr wrote:
>>
>>> the machine is activated through getRawData, which makes it perform a
>>> complete cycle to produce a single packet of formatted data
>>
>>> the initial idea to use a state machine implemented as an inner class
>>> was to:
>>> - bring order in the code
>>
>> Seriously? You think that's more ordered than:
>>
>> DataInputStream in;
>> while (true) {
>> � � � � pushTime(in.readByte());
>> � � � � pushValue(in.readByte());
>> � � � � byte stop = in.readByte();
>> � � � � if (stop == stopByte) {
>> � � � � � � � � commit();
>> � � � � }
>> � � � � else {
>> � � � � � � � � while ((stop = in.readByte()) != stopByte);
>> � � � � }
>>
>> }
>>
>> ?
>>
>> If what you've posted is really what you're doing, and not a huge
>> simplification of what you're actually doing, then you've massively
>> overcomplicated this.
>>
>>> - to take advantage of some time-dependent data (millis) managed by the
>>> outer class RawProtocol (most important)
>>
>> I don't see why you couldn't do that with the above loop.
>
> the snippet is a simplification of the real code, tough it is not so
> much more complicated. Here i made the decision to use a simple
> implementation of a state machine, instead of a sequence of methods, for
> the elasticity i can obtain in the interpretation of the not-so- stable
> underlying protocol.

Do you configure the state machine from a file or similar? If not, it's no
more plastic than code.

People have this idea that once code is written, it's hard to change. This
is wrong.

tom

--
Big Bang. No god. Fadeout. End. -- Stephen Baxter