[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: *Proposed change* _data-tag values give vector length

Right, I cant see any harm in specifying a guess at the length if
you have it (except that it is more complexity in the protocol
--- we dont have the concept of "guesses" anywhere else, though I
could be wrong.) Keep in mind though that, in many cases, the
length of the data may not be known at all,  e.g. when it is
being generated on the fly.  

A suggestion: Dont use Vector in Java if you can avoid it. Its
just a library, and a slow one at that (because of copying).
Better, implement your own linked list structure. That is the
most natural fit for this situation, where you may not know the
size of the data in advance, and you dont have to futz around
copying things over. (It funnny to see Stacks in java implemented
as Vectors, since a much more efficient version is possible
allocating an array of some fixed small size in each
singly-linked cell. You basically just need a Stack for this

   Sender: ramsdell@linus.mitre.org
   References: <Pine.SOL.3.91.970811093253.21068A-100000@piaf>
   Content-Type: text
   Content-Length: 699

   As you all know, I prefer _data-tag less multiline tagged data
   proposal, but let me suggest an improvement for the multiline proposal
   with _data-tag.  I suggest making the tag values a non-negative
   integer which suggests, but does not specify, the number of lines that
   make up the multiline data.  If the constructor of message knows the
   number of lines associated with a value, it sends it, otherwise it is
   free to send zero.  In a Java implementation, this value would be
   given to the Vector constructor when creating the initial empty
   vector.  An MCP parser with a good guess as to the number of lines in
   a message could save many vector allocations that come about due to
   length overruns.