You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This forces us to expose types like attribute.Description which should be internal. Also, this exposes constants like attribute.Int, which should be hidden as well.
We must be very careful about the abuse of interface {}. In the current API, users can passing value as an interface {} type, which might not match the specified type.
Also, users can pass in any reflect.Type as the type, not necessarily chosen from the pre-defined list.
Changing to Int("train.num_pos", 0, ...) makes the compiler checks the type and value are matched.
// Int is an optional int.typeIntstruct {
value*int
}
// NewInt creates an optional.Int from a int.funcNewInt(vint) Int {
returnInt{&v}
}
funcmain() {
b1:=Int() // nil intb2:=NewInt(0) // non nil int with value 0
}
The attribute code may like:
func (dDictionary) Int(namestring, defaultValue optional.Int,
docstring, checkerfunc(int) error) {
...
}
vardict=Dictionary{}.
Int("num_class", optional.Int{}, "doc1", checker1). // default value is nilInt("attr_with_default_value", optional.NewInt(0), "doc2", checker2) // default value is 0
I am afraid that optional is not a good choice. There is a good reason https://stackoverflow.com/a/2032160/724872 that Go doesn't support optional parameters. However, the optional package provides a way to walk around this reasonable constraint.
I would prefer the .Default solution in #42 (comment) for the following reasons:
It removes the constants Bool, String,Int, IntList -- Occam's Razor.
It hides the type Description -- Occam's Razor to minimize the API.
It doesn't brutely add optional parameters thus follows the Go convention.
It is more readable than the current way of constructing Description struct manually and than the use of optional package.
Dictionary.Int(name string, value interface{}, doc string, checker func(int) error)
instead of 2(or 3) methods:
Dictionary.Int(name string, doc string)
Dictionary.Default(value interface{})
// Maybe there would be another method to set checker,
// or set checker in Dictionary.Int method
In this way, we can:
no need Default method.
no need recent field in Set(or Dictionary).
checking whether the default value is valid can be done inside Dictionary.Int.
Activity
wangkuiyi commentedon Jun 17, 2020
Abuse of Global Variables
The following global variables are not needed,
https://github.com/sql-machine-learning/sqlflow/blob/2988c7b155a813c2a5a70035209fb5d523b48df5/pkg/attribute/attribute.go#L165-L172
as they are simply another form of
https://github.com/sql-machine-learning/sqlflow/blob/2988c7b155a813c2a5a70035209fb5d523b48df5/pkg/attribute/attribute.go#L201-L212
wangkuiyi commentedon Jun 17, 2020
Types and Constants Should've Hidden
No need to define type
unknownand constantUnknownbecausereflect.Typeis an interface, which could be assignednilto represent unknown types.https://github.com/sql-machine-learning/sqlflow/blob/2988c7b155a813c2a5a70035209fb5d523b48df5/pkg/attribute/attribute.go#L46
wangkuiyi commentedon Jun 18, 2020
To support the optional default value
sneaxiy commentedon Jun 18, 2020
How about use optional package like https://pkg.go.dev/github.com/markphelps/optional?tab=doc ?
The optional package is implemented like:
The attribute code may like:
wangkuiyi commentedon Jun 18, 2020
I am afraid that
optionalis not a good choice. There is a good reason https://stackoverflow.com/a/2032160/724872 that Go doesn't support optional parameters. However, theoptionalpackage provides a way to walk around this reasonable constraint.I would prefer the
.Defaultsolution in #42 (comment) for the following reasons:Bool,String,Int,IntList-- Occam's Razor.Description-- Occam's Razor to minimize the API.Descriptionstruct manually and than the use ofoptionalpackage.sneaxiy commentedon Jun 19, 2020
@wangkuiyi If we use #42 (comment), how about just write the
Dictionary.Intcode like:instead of 2(or 3) methods:
In this way, we can:
Defaultmethod.recentfield inSet(orDictionary).Dictionary.Int.wangkuiyi commentedon Jun 19, 2020
@sneaxiy I am afraid that we cannot. If we do so, users need to write
Go syntax doesn't allow him/her to write
&1.0fdirectly. This would make the code pretty messy.sneaxiy commentedon Jun 19, 2020
@wangkuiyi Go can convert primitive types like
int,floattointerface{}. The following codes run well in Go.wangkuiyi commentedon Jun 19, 2020
Fantastic! I agree with your proposal. Thank you for letting us know this property of Go!
sneaxiy commentedon Jun 24, 2020
@wangkuiyi The attribute package has been refined by the following PR:
Add named type methods like
Dictionary.Int: Add typed API to pkg/attribute sqlflow#2486 , https://github.com/sql-machine-learning/sqlflow/pull/2496/filesReplace attribute definition with the new added named type methods: Update attribute definition by named type methods and hide attribute.Description sqlflow#2504
Remove global variables
xxxJSON: Remove XGBoostObjectiveJSON sqlflow#2508 , Remove ModelParameterJSON and OptimizerParameterJSON in attribute package sqlflow#2520Hide some unnecessary exported structs and global variables like
attribute.Int,attribute.Description: Update attribute definition by named type methods and hide attribute.Description sqlflow#2504Maybe we can close this issue now.