remember now how easily they
can be used to convert with integers.
YAY!
On Friday, 4 May 2018 20:44:21 UTC+3, Louki Sumirniy wrote:
>
> Well after bashing my head against a brick wall I finally understand what
> a mess it is for my specific purpose to work with Go. Nobody really
>
understand well enough how to use interfaces,
embedding and composition.
On Friday, 4 May 2018 13:13:56 UTC+3, Louki Sumirniy wrote:
>
> Yep, you are correct, more or less. My code is using interfaces and
> panicking when it's fed the wrong thing.
>
> For example, in my test I had a
To use callbacks in Go you must follow Functional Programming rules about
shared data. In simple terms, you cannot share data. You can pass pointers
to shared data structures, and likely will have to but as soon as you start
using also goroutines you will end up with race conditions. To solve
nguage like Rust?
>
>
> I think Go could work.
>
> Matt
>
> On Friday, May 4, 2018 at 1:45:52 PM UTC-5, atomly wrote:
>>
>> Perhaps try another language like Rust?
>>
>> atomly
>>
>> On Fri, May 4, 2018 at 10:44 AM, Louki Sumirniy <louki.s
o could work.
>
> Matt
>
> On Friday, May 4, 2018 at 1:45:52 PM UTC-5, atomly wrote:
>>
>> Perhaps try another language like Rust?
>>
>> atomly
>>
>> On Fri, May 4, 2018 at 10:44 AM, Louki Sumirniy <louki.sumir...@gmail.com
>> > wrote:
ability or compile time type safety.
>
> Le vendredi 4 mai 2018 06:26:59 UTC+2, Louki Sumirniy a écrit :
>>
>> The specifics of how it is done is not as important as why to do it:
>>
>> I am writing this for a later project. It will need at least 5 different,
>
Can you not convert it to an unsafe.Pointer and check for that being nil?
On Tuesday, 8 May 2018 16:49:23 UTC+3, Michael Cohen wrote:
>
> In my case, being a new go learner the following bit of code stumped me. I
> am receiving a interface{} value and I am trying to figure out the best way
> to
How does it perform compared to pre-compilation? I would think it is such a
thin margin it's barely worth doing? Also, order-dependency is a pretty big
problem considering how little Go code will be written in this kind of
order, since it doesn't have to be. I would think therefore that to fix
generation using macros. More than 75% of gomacro code
> is generated with this technique, and I will present the topic at Golab.io
> conference in Italy in October.
> Before that date I should have some documentation available too - they
> reproduce Lisp macros almost literally, but I gues
I don't understand why you are saying this after how many times so many
people have pointed out that
while Condition() { ... }
is expressed as
for Condition() { ... }
The for statement with a single clause IS a while loop. You can make it
explicit by putting semicolons on each side of
Until implies a negation. The presence of unless in perl is a horror
> resulting from the same semantics - I'm sure it seemed like a good idea
> at the time.
>
> On Thu, 2018-05-10 at 23:25 -0700, Louki Sumirniy wrote:
> > I think better to use the context of the english language f
I think better to use the context of the english language for a
pre-condition checked after:
until Condition() { ... }
Or maybe just exactly mimics for, but does not test until after one run of
the enclosed block:
until Init(); Condition(); PostAssignment() { ... }
On Friday, 11 May 2018
it makes to the compiler to enforce all statement blocks regardless of how
many statements inside are wrapped, but I don't think it makes sense to add
two lines just to do something as simple as a break statement.
On Friday, 11 May 2018 11:17:14 UTC+3, Louki Sumirniy wrote:
>
> Until con
.
On Friday, 11 May 2018 11:26:13 UTC+3, Jan Mercl wrote:
>
> On Fri, May 11, 2018 at 10:22 AM Louki Sumirniy <louki.sumir...@gmail.com
> > wrote:
>
> > On that note, I think that most of the ways that gofmt changes things is
> nice but I think I'm disabling its use from now
irst email. I plan to read it in detail and send another
> response. I’m speaking from the idea behind a version of this story:
> http://cs.txstate.edu/~br02/cs1428/ShortStoryForEngineers.htm
>
> Matt
>
> On Friday, May 4, 2018 at 5:28:30 PM UTC-5, Louki Sumirniy wrote:
>>
&
math/big's big.Int has a power function:
https://golang.org/pkg/math/big/#Int.Exp
I wrote a power function for big.Float you can find
here: https://github.com/l0k1verloren/float256/blob/master/float256.go#L82
It doesn't check for overflows because I don't think big.Float overflows
from 64 bit
I have a preferred methtod for emulating do-while:
notdone:=true
for notdone {
if {
notdone = false
}
}
I prefer to use a negative name because I don't see why I should use a
unary operator when I can just use the word NOT and not incur any runtime
cost.
or
for ! {
}
The for
for { . }
is exactly a while loop. The c style for statement's second clause is exactly
this and in c you can do this clumsily with:
for (i=1; ; true ) { . }
Go assumes that a single boolean expression is the same without initial
statement and post block loop statement. If you want to be
It could be effectively added in Go by allowing an optional condition after
break statements.
--
You received this message because you are subscribed to the Google Groups
"golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
It adds absolutely nothing, that's why it should not be accepted. It will
lead to a divergence in the way it's used as well. However I think maybe
run block once before first condition check would be a useful and powerful
addition. Maybe it shows my age that I even know what do-while
I just think that:
for { ... } condition()
would be a useful addition to the language because minimum one run of the
for block is a common need.
Or to avoid any confusion, create a new reserved word:
until condition() { ... }
The lack of explicit minimum one-run in my opinion runs counter to
I could be wrong but float64 is 'float' and 'double float' is float128. I
dunno, I have not tinkered with these imprecise math types. That's just,
essentially, what they were back in the olden days, like 20 years ago. 64
bit was basic float, 128 was double. I have been out of the loop for way
So, the fastest way on the compile-side for making collections of functions
(optionally, tied to some common data type) is using closures? I thought so
also, that's the direction I went instead of interfaces in my own work for
the same reason.
On Sunday, 29 April 2018 16:52:44 UTC+3, Max
I have been struggling with getting the most optimal, non-reflective and
performant way of implementing something that is a bit like OOP method
overloading. As some here may know, I am implementing a novel binary tree
based on complete trees and using ideas from B-heaps in order to achieve
this from the for grammar
because the first clause is a statement not an expression, the second is an
expression, and the third is a statement.
On Thursday, 3 May 2018 12:47:38 UTC+3, Louki Sumirniy wrote:
>
> I am writing code in which I pondered exactly using this kind of thing, it
> invo
I am writing code in which I pondered exactly using this kind of thing, it
involves tree walking on a binary tree, but I decided to scrap this
approach because, although you can't see it so clearly in that C code, it's
executing a function every loop that probably doesn't need to be. your
Mercl wrote:
>
> On Thu, May 3, 2018 at 10:14 PM Louki Sumirniy <louki.sumir...@gmail.com
> > wrote:
>
> > As some here may know, I am implementing a novel binary tree based on
> complete trees and using ideas from B-heaps in order to achieve maximum
> data cache
urgh. Wile I think the C shorthand if/then notation is kinda cool, I really
think you can easily go too far with programming where all the time you
save on keystrokes you pay by using the shift key a lot more and having to
really carefully read. Maybe after a time it would be cool but I prefer
The reason I am trying to avoid using a code generator is because it isn't
integrated into VScode. I write a small section of code, then I write tests
that I have set to show logging output, so I can quickly figure out when
something is wrong. Code generation adds a lot of manual work to this.
There is a default value for everything in Go. Null. 0, "" and nil. As
someone else said, if you want a parameter to be optional you probably need
...interface{} and then infer no parameter as 'use the default'. Going a
little further, you can build default values into a constructor function
It seems to me the only way to achieve this would be to allocate a []byte
twice the size you need, to be sure, then get the address of the start and
offset it (if necessary) until it is a number (as in uintptr) divisible by
16, then it would be correctly structured. I would think you will find
I have to agree. The idiomatic solution would be defining multiple
functions that wrap around another, and it is not onerously boilerplatey.
As Ian says, default values do constitute effectively function overloads.
There is reason why function overloading is not available in Go. Just go
look
gt;> I think having default values for parameters is just a feature which
>>> will make codebase readable and smaller than before.
>>>
>>> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy
>>> wrote:
>>>>
>>>> Th
This is in the next section but it's probably even more important:
There is one more aspect of naming to be mentioned: method lookup is always
by name only, not by signature (type) of the method. In other words, a
single type can never have two methods with the same name. Given a method
x.M,
The distinction you are missing is that Go only considers the *name* of an
interface method to be unique, meaning only one parameter definition is
allowed per name. What this means is that in Go these have to be separate
functions and by definition, differently named. This is why I am
, hard to solve bugs.
On Friday, 24 August 2018 14:47:21 UTC+2, Louki Sumirniy wrote:
>
> This is in the next section but it's probably even more important:
>
> There is one more aspect of naming to be mentioned: method lookup is
> always by name only, not by signature (type) of the m
I discovered quite by accident and now I can't find anything saying as
such, but this example
package main
import (
"fmt"
"errors"
)
type Thing struct {
err error
}
type thing interface {
Error() string
}
func (t *Thing) Error() string {
return t.err.Error()
}
func main() {
t :=
structure because they used default values. I think
> having default values for parameters is just a feature which will make
> codebase readable and smaller than before.
>
> On Thursday, August 23, 2018 at 4:38:23 AM UTC+4:30, Louki Sumirniy wrote:
>>
>> There is a default va
to say all of the python application should rethink
> and re-write their structure because they used default values. I think
> having default values for parameters is just a feature which will make
> codebase readable and smaller than before.
>
> On Thursday, August 23, 2018 at
I think there is no really big reason to make a special tuple type for
return values. The extra burden comes in specifying the type and wrapping
the list in curly brackets, and predefining the elements in a type struct
declaration. I am writing a dense binary tree implementation (dense as in
I am pretty sure that you will run into problems with this. On one hand
passing pointers could lead to a write after a read, and on the other hand
with pass by value you could get an out of date value and then stomp over
another process write. I'm pretty sure the race detector will flag this.
I only just finally wrapped my head around this stuff and forgive me if I
have missed the point of the question but this is what my code has:
type AbstractType alias/struct {}
type abstractthing interface {
DoSomething(interface{})
}
func (a *AbstractType) DoSomething(b AbstractType) {
}
ne which will take up space on next slice's bytes.
>
> On Saturday, April 21, 2018 at 2:30:53 PM UTC+5:30, Kaveh Shahbazian wrote:
>>
>> @ Louki Sumirniy
>> Slices are values AFAIK. There is no passby pointer.
>>
>> And the point is, race detector does not flag an
Your syntax is wrong. I think you mean this:
var someInterfaceValue interface{}
// do something that puts a value in above variable
switch someInterfaceValue {
case true:
// do something
default:
// do something else
}
On Saturday, 21 April 2018 16:30:22 UTC+3, b97...@gmail.com
:31:01 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 6:57 AM Louki Sumirniy <louki.sumir...@gmail.com
> > wrote:
>
>>
>> func (b *Bast) Parent(c Cursor) Cursor {
>> if c.Index == 0 {
>> c.Err = errors.New("No parent from the root")
code, and external also to the data it points at, because there
could be multiple trees being operated on within one application using this
library.
On Thursday, 19 April 2018 08:31:01 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 6:57 AM Louki Sumirniy <louki.sumir...@gmail.com
If your variable and function names don't explain what is going on, you
will encounter a big maintenance problem with your code as non-updated
comments contradict your unreadable code.
Very occasionally I find a use for attention-grabbing comments, number one
for this, and personally I
) but singular in
their literal form.
On Thursday, 19 April 2018 16:06:42 UTC+3, Jan Mercl wrote:
>
> On Thu, Apr 19, 2018 at 2:51 PM Louki Sumirniy <louki.sumir...@gmail.com
> > wrote:
>
> > Sorry for the self-promotion but it was relevant in that I was working
> on how to ti
I personally think that in the specific case of OOP code syntactic sugar
declarative structuring stuff - and maybe also godoc header comments such
as within type struct and type interfaces would make Go code even more
readable. There is limits to how far readability and consequential
You need to show the input file also. I can only guess this has something
to do with maybe cr/lf? What happens if you add a distinct separator to the
input such as a semicolon?
On Thursday, 19 April 2018 20:31:56 UTC+3, Alex Dvoretskiy wrote:
>
> Hello Golang-nuts,
>
> Following code reads data
help on
> the Go front better with a foundation.
>
> Matt
>
> On Tuesday, April 24, 2018 at 9:22:21 AM UTC-5, Louki Sumirniy wrote:
>>
>> Reading through the wikipedia description of a heap, and especially a
>> binary heap... it's a heap. But that's not a sexy name!
ins).
I don't know anything about what actual result it will have, but I am
building it anyway, and I will use closures because I personally prefer the
notation.
On Wednesday, 25 April 2018 10:48:28 UTC+3, rog wrote:
>
> On 25 April 2018 at 08:05, Louki Sumirniy
> <louki.sumir...@gm
to maintain
a high fill ratio.
On Wednesday, 25 April 2018 12:08:17 UTC+3, Louki Sumirniy wrote:
>
> I think that it's not necessarily non-idiomatic to use closures instead of
> interfaces in Go, it's more that Go has had interfaces longer than it's had
> closures, and so more code has
conceptual model have
changed, and big thanks to you guys, I have to rework the design to account
for this. Thanks :p
On Wednesday, 25 April 2018 15:11:15 UTC+3, rog wrote:
>
> On 25 April 2018 at 10:24, Louki Sumirniy
> <louki.sumir...@gmail.com > wrote:
> > As you look
I essentially am trying to find an effective method in Go, preferably not
too wordy, that lets me create an abstract data type, a struct, and a set
of functions that bind to a different data type, and that I can write,
preferably not in too much code, a change that allows the data type of the
d. Why not an
> interface containing these varying functions as methods instead of function
> types?
>
> Matt
>
> On Sunday, April 22, 2018 at 5:20:12 PM UTC-5, Louki Sumirniy wrote:
>>
>> I essentially am trying to find an effective method in Go, preferably not
>>
https://github.com/golang/go/issues/24996#issuecomment-383424588
It seems that (Type).FuncName in the assignment binds to the struct... I am
glad I found an answer so quickly because my hackish solution was gonna be
implemented today.
On Monday, 23 April 2018 02:20:47 UTC+3, Louki Sumirniy
There does still need to be a mutex for reads on an element that is being
written to. It's a minor edge case but it could cause a serious problem
when it hoppens.
On Monday, 23 April 2018 08:36:38 UTC+3, Tamás Gulácsi wrote:
>
> If there's no uncoordinated write and read/write of the same slot,
stuff (in my case
it's just an array, but it could easily be a storage protocol or network
protocol) would help immensely in implementing pluggable architectures.
On Monday, 23 April 2018 08:23:24 UTC+3, Louki Sumirniy wrote:
>
> https://github.com/golang/go/issues/24996#issuecomment-383
if a.Left == nil {
> return false
> }
> return a.Equal(a.Left.Element)
> }
>
> type Element interface {
> Equal(Element) bool
> Null() bool
> }
>
> Matt
>
> On Monday, April 23, 2018 at 8:55:14 AM UTC-5, Louki Sumirniy wrote:
>>
>&
he rule.
>
> Le dimanche 22 avril 2018 02:53:14 UTC+2, Louki Sumirniy a écrit :
>>
>> Your syntax is wrong. I think you mean this:
>>
>> var someInterfaceValue interface{}
>>
>> // do something that puts a value in above variable
>>
>> switch som
The name could use some work, stutter is a no-no in Go. What kind of state
does it hold? User profiles? MMO game world database? Is your scope too
broad? I see that it looks like a geography database, so it would make more
sense to call it 'geo' or something like this. Also, for such a database
This git repository shows an example of all the common conventions for
build layout https://github.com/golang-standards/project-layout
On Tuesday, 24 April 2018 08:26:49 UTC+3, vteja...@gmail.com wrote:
>
> Thank you Matt, I will start reading as you mentioned.
>
> BR,
> Teja
>
> On Monday,
and are just for the purpose of
> demonstration.
>
> The problem is the package state, one whole package to just hold a type.
>
> On Tuesday, April 24, 2018 at 10:36:29 AM UTC+4:30, Louki Sumirniy wrote:
>>
>> The name could use some work, stutter is a no-no in Go. Wh
/418af6fc24480cbbc2d7b72bab794f0375439f9c
On Tuesday, 24 April 2018 10:19:56 UTC+3, Louki Sumirniy wrote:
>
> I looked at the OP again and I have created a struct embedding with
> interface type for a similar purpose as you have in mind.
>
> I'm not sure how to condense it exactly
.
On Monday, 23 April 2018 20:06:08 UTC+3, rog wrote:
>
> On 22 April 2018 at 23:20, Louki Sumirniy
> <louki.sumir...@gmail.com > wrote:
> > I essentially am trying to find an effective method in Go, preferably
> not
> > too wordy, that lets me create a
, it's one
of the elements of the heuristics I have developed so far.
On Tuesday, 24 April 2018 12:02:44 UTC+3, Louki Sumirniy wrote:
>
> I just dug into the data structure spec for Btrfs, figuring it would have
> trees in it, and no, they are not implemented in the way I am working here
well later
anyway, regardless of whether this succeeds or fails when the rubber hits
the road.
On Tuesday, 24 April 2018 11:58:39 UTC+3, Louki Sumirniy wrote:
>
>
>
> On Tuesday, 24 April 2018 11:15:34 UTC+3, rog wrote:
>>
>> On 23 April 2018 at 19:58, Louki Sumirniy
>
On Tuesday, 24 April 2018 11:15:34 UTC+3, rog wrote:
>
> On 23 April 2018 at 19:58, Louki Sumirniy
> <louki.sumir...@gmail.com > wrote:
>
> > I set many of those identifiers to export because I wanted to keep
> separate
> > derived libraries that re
I'll just be brief this time and hit the points quickly:
Yes, technically it is a Complete Binary Tree but you won't find a Complete
Implementation of one anywhere, I have looked, and there isn't. The concept
has been rejected without being tested by anyone who has considered it at
least what
to do it, you realise 'oh, that's why go doesn't like it'.
soo, for me :) unsubscribing and not ruminating any further
(*sigh of relief in the peanut gallery*) :D
On Tuesday, 24 April 2018 14:59:22 UTC+3, Louki Sumirniy wrote:
>
> I'll just be brief this time and hit the points q
Reading through the wikipedia description of a heap, and especially a
binary heap... it's a heap. But that's not a sexy name! Technically it's
not a heap because it sorts left to right, heaps sort bottom to top.
I am stripping down my code and directly declaring the struct variables as
I think that the issue with dealing with multiple conditions and certain
pre-defined response patterns is at the centre of the error handling
problems.
My suggestion is here: https://github.com/golang/go/issues/27794 and
centers around extensions of the return and switch syntax.
The solution
in programming languages putting the type first basically only appears in C
and its (ill-born) children. But the reversal of word order like this is
also present in norse and slavic languages with the definite article. It's
actually the counter-intuitive pattern, and having learned to speak
This is something that I have seriously considered to be the right way for
Go to express other generic types. I am in fact in the middle of a project
at the moment where I have created a pair of generic byte buffer types, one
is the regular kind, the other uses memguard locked buffers, for
I am quite a fan of switch statements, they can make a list of responses to
a change in state very readable and orderly. But you have to remember a few
things about them. They don't evaluate in any definite order, so any
conditions that need more than one response need to use a fallthrough,
Ah, I wasn't quite clear on that. That does make them a lot even more
useful.
On Monday, 24 September 2018 11:12:38 UTC+2, ohir wrote:
>
> On Mon, 24 Sep 2018 01:37:56 -0700 (PDT)
> Louki Sumirniy > wrote:
>
> > I am quite a fan of switch statements, they can mak
In my opinion the interface represents the simplest way to allow operator
overloading. With an inbuilt interface that covers all the symbols and some
sort of category to break them down (boolean logic, binary logic,
arithmetic, misc unary, prefix infix and postfix). Then you can have the
built
I think the thing everyone who likes operator overloading like mainly is
being able to do infix and postfix syntax, instead of only prefix
(function). But then also what do you do about interfaces that also
implement an operator interface? I'd guess biggest reason to not do it is
1) no human
Goto isn't used often in Go because it has to be invoked on its own line
inside a conditional statement block, which often can perform the same
decision if you think it through, as well as moving shared elements into
functions that share the receiver or have common interfaces, outside of the
Using named return values and this construction you can drop all those
returns in each case block to outside the block. You only need to spend an
extra line if you have to break out of it by return or break.
On Monday, 24 September 2018 16:01:23 UTC+2, Lucio wrote:
>
> You never used:
>
>
If you don't mind it involving a small background processing overhead, you
could use a goroutine running a hashcash style iterative hash chain
generation searching for a specified number of zero bits at one (or both)
ends of the resultant hash before you run out of bits. This is extremely
A map[string]interface{} can hold an arbitrary, string labeled collection
of any types. You just need to have a type switch and cover all the
possible inputs for it.
The concurrency is safe as long as only one process is writing to variables
at once. If you need multiple concurrent processes
There is a lotta stuff that can be done with html and css now without
javascript, but for this kind of application I think that the display side
(the webkit/blink engine) has to have a websocket to the server backend to
allow pushing updates to the DOM, at least refreshes. But this is not a
do it.
>
> Sent from my iPhone
>
> > On Sep 22, 2018, at 8:52 PM, Ian Denhardt > wrote:
> >
> >> On Saturday, 22 September 2018 16:47:00 UTC+2, Louki Sumirniy wrote:
> >>
> >> I think the thing everyone who likes operator overloading like m
; On 9/23/18, Robert Engels > wrote:
>> >> Issues like these highlight the deficiencies of Go compared to Java.
>> The
>> >> Java designers understood languages far better, and from the start
>> realized
>> >> that identity and reference equ
I would be guessing that's because the response is actually thus an array
(square brackets around anything mean a list of same-typed fields without
keys) and you need to thus use response[0] to get it if there is only one,
or process it in a for loop iterating using range. Probably you could
I would expect at minimum there is a field in the type in the AssignTo
field (it is a struct, I am guessing) that you could use. In VSCode you can
control-click on type names and it opens up the declaration of the type
(same for functions and variables too)
On Monday, 10 December 2018 09:10:16
I have done this many times. Some repositories are more of a pain than
others to move. I was amused to learn after having done this with
github.com/btcsuite/btcd, that the btcjson, btcec, btcutil and btclog repos
all were separate but quite tightly bound both to each other and it took me
about
C/C++ way of working with these things requires specifying the start and
end point using pointer arithmetic, which is pretty cumbersome considering
how often it is needed. I think what Ian said is probably the most complete
way to deal with it.
But probably you can also do it using the unsafe
The main reason for the prohibition against circular imports is that you
have to add overhead in the processing to determine when to stop. From an
architectural perspective it also makes sense - most often if you stop for
a moment and think about what you are building, usually if you are
I agree about the stutter naming. The name should at least specify the
bitwidth of the integral and fractional parts, to follow the pattern of the
fixed width types already existing. Fixed is easy enough to infer that it
is a fixed point type, by the package. You could name the types based on
The implicit type inferred from an integer is always 'int'. This is a 64
bit signed integer and thus has a maximum width of 63 bits. In Go, you
should not assume sign or width of an untyped implicit conversion, as the
'int' and 'uint' types default to the size of processor registers, which
are
m!
Yes, using pure integer values for currency is generally the best way to
deal with it. The Bitcoin standard is that 1 BTC = 10,000,000 'satoshis'.
Many rightly point out that this is a stupidly small precision, but for the
time being is ok. I personally would expand this, and just use
on
nonlocal types. I think for that you need type aliases.
Like many aspects of Go, you have to think like the computer to express
your intent correctly.
On Thursday, 6 December 2018 04:05:36 UTC+1, Louki Sumirniy wrote:
>
> The main reason for the prohibition against circular imports is th
I have been doing a lot of work involving essentially declarative
(nominally) complex data types involving several layers of encapsulation.
I had seen here and there examples of this 'Fluent' method-based pipeline
chaining, with methods passing through receivers to invoke multiple
distinct
I have become quite interested in tail-call optimisation and more distantly
in code that assembles trees of closures all tied to the same scope through
parameters to reduce stack management for complex but not always
predictable input.
As I have learned from some reading, tail call
oh, just one last point after a re-read - a great deal of what is required
to implement generics, in go, does not need to change the syntax of the
language, except where it concerns that CCR - (as replacing the builtin
numeric types especially would lead to massive overhead in dereferencing),
I am in the middle of implementing a generic tree type as part of a CLI
flags/configuration package, and a key goal in my design is to make the
declarations it parses as easy to read as possible, and as far as possible,
avoiding too much boilerplate.
Yes, nothing new there, but in the
stages of the design
process, is that what is added doesn't take something away, especially
something that isn't obvious and explicit. The most dangerous bugs are the
least visible.
On Tuesday, 26 February 2019 00:37:50 UTC+1, Burak Serdar wrote:
>
> On Mon, Feb 25, 2019 at 3:06 PM Louki Su
1 - 100 of 179 matches
Mail list logo
