I thought the main was special cased, since the app band is based on the
directory not the package.
> On Dec 3, 2018, at 3:04 AM, roger peppe <rogpe...@gmail.com> wrote:
>
> On Mon, 3 Dec 2018 at 07:40, robert engels <reng...@ix.netcom.com> wrote:
> > Roger,
> >
> > I experimented with the import name (rather than dot import), and came up
> > with this:
> >
> > type Order struct {
> > sync.RWMutex
> > Instrument
> > Id OrderID
> > ExchangeId string
> > Price n.Fixed
> > Side
> > Quantity n.Fixed
> > Remaining n.Fixed
> > OrderType
> > OrderState
> > RejectReason string
> > }
> >
> > But I’m still not sure it’s great. The n (number) has some meaning, and it
> > definitely reads easier than fixed.Fixed, but I what I’m really trying to
> > convey is that “Fixed” is a top-level type, on equal footing with ‘string’.
>
> But it really isn't a top-level type on an equal footing with string. Type
> "string" is defined by the language and is common with every other Go program
> in existence. Your "Fixed" type may be one of many implementations, each with
> its own particular set of operations and conventions.
>
> That said, you could do:
>
> type fixed = fixed.Fixed
>
> > OrderID is declared in this package, so it reads with the desired
> > simplicity, and it just seems wrong that I can’t declare Fixed to have the
> > same treatment just because it comes from another package.
>
> Knowing which things come from external packages is an important part of
> understanding the code.
>
> BTW I wonder if a single capital letter might work well for single letter
> import identifiers, because that's a space that's not commonly used (with the
> exception of the "C" pseudo import). e.g. N.Fixed. Then it wouldn't clash
> with commonly used single letter identifiers such as "n".
> > Anyway, I’ve read through your proposal, and I didn’t even think it was
> > possible… :)
> >
> > I thought the last segment needed to match the package name. What would be
> > the rationale for not having that be the case (i.e. why is that even
> > supported ?)
>
> Trivially, every "main" package has this issue, as does any package with a
> trailing major version (e.g. google.golang.org/api/compute/v1,
> gopkg.in/yaml.v2, cloud.google.com/go/container/apiv1). There are quite a few
> packages that use a punctuation-separated last component (e.g.
> github.com/juju/persistent-cookiejar, code.google.com/p/biogo.llrb) and
> others that just seem to use a different identifier anyway (e.g.
> upspin.io/pack/eeintegrity has name "ei" not "eeintegrity").
>
> I don't think it's a good idea to encapsulate some of the above conventions
> in the language spec; better just to define a simple rule and an easy way to
> get around it when it doesn't fit, I think.
>
> cheers,
> rog.
>
> PS embedding Mutex into a public is generally considered not to be a good
> idea, as it means that external code can break mutex invariants. It's
> considered better to keep mutex-manipulating code encapsulated inside methods
> or functions - that way, all lock manipulations can easily be audited.
> --
> 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 golang-nuts+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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 golang-nuts+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
