[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: API Design
- From: tobias@...
- Date: Tue, 19 Sep 2017 00:34:38 +0200
Quoting Frank Kastenholz <email@example.com>:
Are what I personally like
Or subscripts ala buffer[start,end] :-)
More important than that are, imho, some higher level issues like
Consistency --- do it the same everywhere (as opposed to memcpy vs
strcpy; one is source, dest and the other is dest,src.... grrrr)
Also keep it intuitive ... e.g., most people will the 1st arg is
always the start, so don't have the normal mode be xxxx(start,len)
and then have a 1-argument variant of xxxx(len) with the buffer
start being an implied 1st argument.
And .. having implied additional optional arguments is something
I've discouraged in the past. Typing the additional arguments is no
It stresses the "do you really want xxx for argument n?" In the
programmers mind .... as well as the "we really mean xxxx!" In the
mind of the next programmer to read the code
That raises an interesting question. Currently I have a couple of
ways to create a Buffer( not the segment ), and they are inconsistent:
b = Buffer( 1024 ) -- empty Buffer with 1024 bytes
s = 'This is some example content'
b1 = Buffer( s ) -- buffer filled with s, #b1 == #s
b2 = Buffer( b1 ) -- buffer filled with content of b1; #b1 == #b2
-- this is a true clone, not a reference
sg = b1:Segment( 1, 5) -- Segment[1:5]; #sg == 5
b3 = Buffer( sg ) -- buffer with content of sg, #b3 == #sg
-- true clone of content
b4 = Buffer(14, b1) -- buffer with first 14 bytes from b1
As you can see the arguments are inconsistent;
either (number, content) or (number) or (content)
Any ideas how to reconcile that?