On Mon, Dec 3, 2018 at 4:25 PM Robert Engels wrote:
>
> Btw, I am working on some issues/proposals/tools that I think will help the
> situation - not just complaining.
I'd like to hear more about what you're planning to do.
>
> > On Dec 3, 2018, at 5:19 PM, Robert Engels wrote:
> >
> > Probabl
Btw, I am working on some issues/proposals/tools that I think will help the
situation - not just complaining.
> On Dec 3, 2018, at 5:19 PM, Robert Engels wrote:
>
> Probably another thread unto itself, and some of the issues have already been
> corrected like the addition of modules.
>
> On
Probably another thread unto itself, and some of the issues have already been
corrected like the addition of modules.
One of the biggest is dynamic code changes at runtime, while debugging, a lot
of web apis, etc. Often there’s a lot of steps to get to X in an enterprise
app. It’s a much slow
On Sun, Dec 2, 2018 at 11:09 PM Robert Engels wrote:
>
> I agree that is an important consideration, but it seems less important if
> the packages are small and focused.
>
> I think an important point to consider is that there are systems apps, and
> enterprise apps. These rules seem well suited
I don’t think that’s an issue. You only have references to both Employee in the
integration code, and that should probably always use fully qualified names -
if I’m understanding your concerns, but I’m not sure I am.
> On Dec 3, 2018, at 10:23 AM, Bakul Shah wrote:
>
>
>
>> On Dec 3, 2018,
Whilst not exaclty the peek of modern tooling, grep is one method of
checking where and how your package is used. That's a lot clearer without
dot imports.
I've never used a dot import, and don't think I have seen one in the
wild. Allowing dot imports feels like a bit of a wart (but one that is
e
> On Dec 3, 2018, at 8:08 AM, Robert Engels wrote:
>
> I understand that, and when working in code that uses both types, which is
> probably limited, you fully qualify. This is pretty standard stuff in the
> enterprise world, as well architected solutions are segmented, so you only
> encoun
Anyway, thanks all for the input. I am continuing to review other large code
based for real world examples for what works and what doesn’t and having the
input of the community makes understanding the conventions easier.
> On Dec 3, 2018, at 10:08 AM, Robert Engels wrote:
>
> I understand tha
I understand that, and when working in code that uses both types, which is
probably limited, you fully qualify. This is pretty standard stuff in the
enterprise world, as well architected solutions are segmented, so you only
encounter this problem at the integration points, and that code is quali
On Dec 3, 2018, at 6:52 AM, Robert Engels wrote:
>
> I think people are misunderstanding my equal footing need. I don’t mean for
> all applications, I mean for a application.
>
> Here’s another example. You have a enterprise payroll application. You have a
> model package. You have model.Empl
On Mon, 3 Dec 2018 at 14:52, Robert Engels wrote:
> I think people are misunderstanding my equal footing need. I don’t mean
> for all applications, I mean for a application.
>
> Here’s another example. You have a enterprise payroll application. You
> have a model package. You have model.Employee
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 wrote:
>
> On Mon, 3 Dec 2018 at 07:40, robert engels wrote:
> > Roger,
> >
> > I experimented with the import name (rather than dot import), and cam
I think people are misunderstanding my equal footing need. I don’t mean for all
applications, I mean for a application.
Here’s another example. You have a enterprise payroll application. You have a
model package. You have model.Employee. Having to use model.Employee throughout
the application
On Dec 2, 2018, at 11:39 PM, robert engels wrote:
>
> what I’m really trying to convey is that “Fixed” is a top-level type, on
> equal footing with ‘string’.
a) it is *not* on equal footing with the built in types of Go.
b) it can't be, as "Fixed" by itself not well defined. The
Fixed type i
On Mon, Dec 3, 2018 at 10:05 AM roger peppe wrote:
> That said, you could do:
>
> type fixed = fixed.Fixed
FTR: That's invalid code, it redeclares 'fixed'. (Go forbids the same
identifier to live in package scope and file scope.)
--
You received this message because you are subscribed to the G
On Mon, 3 Dec 2018 at 07:40, robert engels 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
>Quanti
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
RejectR
I agree that is an important consideration, but it seems less important if the
packages are small and focused.
I think an important point to consider is that there are systems apps, and
enterprise apps. These rules seem well suited to systems apps, but maybe not so
well suited to business ente
On Sat, Dec 1, 2018 at 7:25 PM Robert Engels wrote:
>
> The way to fix it though it just to use dot imports, and encourage it! The
> only time dot imports don’t work is when there isn’t package stutter. Seems
> like a no brainer and you get the best of both worlds.
Go programs that do not use d
> Do you really think you are losing information if this becomes:
>
> func matches(p Policy, a authorizer.Attributes) bool {
>From my point of view, yes it makes a big difference if I see a
package-qualified identifier, because I know that it's invoking some other
package's abstraction. I am very
For what it's worth, in all this time, context.Context still looks clumsy
to me and I wish you'd picked context.Ctx :)
My certainty level here is high, the intensity level is low. It's like: I'm
pretty sure I like the red backpack better than the black one. But the
black one is fine :)
Niko
O
If can go as far as
List list = sort(reverse(somelist))
I understand the import problem is not an issue when writing a package, but
it’s a big issue when the use of the package is extensive, like domain types.
It’s just cumbersome noise at that point, and a solution is needed IMO.
> On Dec 2,
That's pretty different to a dot import in Go. If the imports below
gave you
List list = singletonList(someobject)
Then they would be comparable - the static imports are more comparable
to Go's dot imports, but then in your next post you say that they're
mainly used for constants, "although for
Quoting robert engels (2018-12-02 01:55:17)
> added to Go, but I am not sure if the package has a few related types
> (which it should IMO) it is any better than
>
> import . “package”
This also exposes stand-alone functions, constants etc. which doesn't
come up in Java.
I think the stutter real
In both Java and C++ (statically compiled languages), Google's style guides
prohibit "wildcard"-style imports of an entire library:
https://google.github.io/styleguide/javaguide.html#s3.3.1-wildcard-imports
https://google.github.io/styleguide/cppguide.html#Namespaces
I believe the restriction is
Quoting robert engels (2018-12-02 01:43:45)
> import * + type inference + dynamic language = hell
Can't have type inference without types, so it's just the dynamic bit,
but I basically agree -- combined with the fact that you can do nonsense
black magic with the import machinery at runtime in Py
I was thinking the similarly, which is why I thought about the List case.
In Java, however you get there, it is just referred to as List
In Go, it is going to be list.List
And in a competing implementation it is going to be container.List or whatever
package the author came up with.
That’s a b
I think it is especially problematic for python because:
import * + type inference + dynamic language = hell
in my book.
> On Dec 2, 2018, at 12:26 AM, Ian Denhardt wrote:
>
> Quoting robert engels (2018-12-02 00:59:31)
>
>> Granted, their package structure seems poor in my opinion, but yo
Based on your explanation, my original understanding of the semantics
were correct. This:
> import java.util.Collections;
..is not a dot import -- a dot import makes visible every (exported)
identifier in the package. This just exposes the one identifier --
Collections. I don't have a problem wi
Quoting robert engels (2018-12-02 00:59:31)
>Granted, their package structure seems poor in my opinion, but you
>can't talk bad about k8s.
Of course you don't lose anything by getting rid of the package names if
the package structure doesn't make any sense in the first place.
>And pr
And when reading through code no Java developer goes, hmmm I wonder what a List
is - since List in idiomatic use is the List interface from java.util.List.
Could it be another List type, possibly the java.awt.List, but that’s only used
in awt related code, and if it’s truly a different List type
The ‘static import’ allows you to refer to things like this:
import static java.util.Collections.sort;
public class ScratchTest {
public static void main(String[] args) {
java.util.List list = sort(java.util.Collections.singletonList(new
Object());
}
}
but typically, the static
The .* doesn’t mean what you think it does - that just means all of the classes
in the package. It is no different than listing them each.
When you use
import java.util.Collections;
import java.util.List;
You are actually doing a dot import, so you can in the code just refer to it as
so
List
As some supporting evidence, here is a method signature in k8s:
func matches(p abac.Policy, a authorizer.Attributes) bool {
The interesting aspect is that this method is in package abac, except it is in
pkg/auth/authorizer/abac
and the one being used in the method
pkg/apis/abac
Do you really
Quoting Robert Engels (2018-12-02 00:19:40)
> I know everyone hates it when I reference java but it has had dot
> importsat the package level since day one. I won’t repeat why that
> matters. It’s never been a problem.
>
> I don’t think I ever heard someone complain it was a problem in
> working in
I know everyone hates it when I reference java but it has had dot imports at
the package level since day one. I won’t repeat why that matters. It’s never
been a problem.
I don’t think I ever heard someone complain it was a problem in working in
Java, why is it such a problem in Go? I’m suspecti
Quoting Robert Engels (2018-12-01 22:25:06)
> The way to fix it though it just to use dot imports, and encourage it!
> The only time dot imports don't work is when there isn't package
> stutter. Seems like a no brainer and you get the best of both worlds.
My experience in every language I've work
I would've probably chosen context.State or context.Type;
but to be frank "Context" always seemed a bit too generic
to me. Looking at its definition it seems like something
to carry a bunch of random stuff. Sort of like a knapsack!
Naming is not easy. As usual Dijkstra has something
interesting to
I think context.Context is fine, it’s weird though I’ll admit.
The way to fix it though it just to use dot imports, and encourage it! The only
time dot imports don’t work is when there isn’t package stutter. Seems like a
no brainer and you get the best of both worlds.
You have similar problem
For what it's worth, we considered various ways to shorten context.Context
before releasing it as open source. The obvious choice would be context.C,
but I was concerned this would encourage people to name their context
variables c, which conflicts with the common short name for channel
variables.
I agree. You need to understand the expected usage patterns (and possibly other
external and internal constraints) before you can claim that any design “needs
change”.
> On Dec 1, 2018, at 12:18 PM, Bakul Shah wrote:
>
> Reducing stutter.Stutter is a good thing. But coming up with meaningful
Reducing stutter.Stutter is a good thing. But coming up with meaningful
names ThatDontTakeHalfALineAndReduceCodeDensity is often quite
hard (but ultimately rewarding as it forces you to think more clearly).
And languages and practices evolve as people gain more experience
so early practices should
I can understand that and it seems reasonable but if I’m writing a new Ring
“class” and it supports both a standard and a concurrent version, I’m probably
not going to create two packages. I would create one package named ring and
have NewRing and NewSyncRing. Which is what I and I think you are
On Sat, Dec 1, 2018 at 9:53 AM Robert Engels wrote:
>
> That was my point. The earliest practitioners and language designers used the
> construct extensively but now others claim it is not the way. I find it hard
> to believe that in testing the original Go design the creators didn’t think
> ab
That was my point. The earliest practitioners and language designers used the
construct extensively but now others claim it is not the way. I find it hard to
believe that in testing the original Go design the creators didn’t think about
this - which means they decided it was fine. So why the cha
In the cases of time and context, the stutters appear in a primary type
that is important to the package, but rarely appears directly in normal API
usage.
E.g., time.Now(), context.Background().
Stutter is to be avoided. The package name can provide context. But
stutter is preferred to, e.g. ti
In another thread, it has been brought up that things like time.Time are no
good. But this format is pervasive. Even newer packages like context.Context.
It seems to have been this way for a long time.
It there some reasoned paper on why this is now so frowned upon?
--
You received this messa
47 matches
Mail list logo
