Agree. What would then make the balance to go one side or another?
Any ideas?
Right now I'm facing this problem where I have a chain of delegation where
I interact with multiple external gems each one with different "opinions".
What is the best way of handling that.
The best way would be to delegate the hash from the entrypoint right to the
external gem method call. For each gem I have an adapter but each adapter
inherits from a chain of base classes.
It is to complex to put hash contracts everywhere to cope with this string
vs symbol ambiguity.
The contract should be in the beginning at the interface and that's it. It
puts me crazy to have to deal with this at the adapter level.
Now imagine my frustration to have be worried scout it in every base class
of the chain.
Is this the sun of a mountain or what?
Ruby is about anything but this.
What is supposed to be for many people "little sand" in a complex gear like
mine becomes a HUGE problem.
It is, of course, just a guide, but I like to follow it as much as possible
where it doesn't actively conflict with the established style of whatever
I'm working on.
···
On Mon, 16 Jan 2017, 15:25 Daniel Ferreira, <subtileos@gmail.com> wrote:
On Mon, 16 Jan 2017 at 15:10, Carlo E. Prelz <fluido@fluido.as> wrote:
Subject: Re: Hash productivity
Date: lun 16 gen 17 03:04:53 +0000
Quoting Daniel Ferreira (subtileos@gmail.com):
> For instance, If we do have to leave with booth strings and symbols,
shall
> we favor always symbols over strings or the opposite? Why?
Neither, of course. Sometimes strings, sometimes symbols.
Rigid rules are fragile, they usually do not lead to better code.
Carlo
--
* Se la Strada e la sua Virtu' non fossero state messe da parte,
* K * Carlo E. Prelz - fluido@fluido.as che bisogno ci sarebbe
* di parlare tanto di amore e di rettitudine? (Chuang-Tzu)
Agree. What would then make the balance to go one side or another?
Any ideas?
Right now I'm facing this problem where I have a chain of delegation where
I interact with multiple external gems each one with different "opinions".
What is the best way of handling that.
The best way would be to delegate the hash from the entrypoint right to
the external gem method call. For each gem I have an adapter but each
adapter inherits from a chain of base classes.
It is to complex to put hash contracts everywhere to cope with this string
vs symbol ambiguity.
The contract should be in the beginning at the interface and that's it. It
puts me crazy to have to deal with this at the adapter level.
Now imagine my frustration to have be worried scout it in every base class
of the chain.
Is this the sun of a mountain or what?
Ruby is about anything but this.
What is supposed to be for many people "little sand" in a complex gear
like mine becomes a HUGE problem.
On Mon, Jan 16, 2017 at 4:25 PM, Daniel Ferreira <subtileos@gmail.com> wrote:
Any ideas?
Right now I'm facing this problem where I have a chain of delegation where I
interact with multiple external gems each one with different "opinions".
What is the best way of handling that.
The best way would be to delegate the hash from the entrypoint right to the
external gem method call. For each gem I have an adapter but each adapter
inherits from a chain of base classes.
It is to complex to put hash contracts everywhere to cope with this string
vs symbol ambiguity.
The contract should be in the beginning at the interface and that's it. It
puts me crazy to have to deal with this at the adapter level.
Now imagine my frustration to have be worried scout it in every base class
of the chain.
Is this the sun of a mountain or what?
Ruby is about anything but this.
What is supposed to be for many people "little sand" in a complex gear like
mine becomes a HUGE problem.
As far as I can judge from my time on the list,
the "traditional" posting style here is "interleaved",
quoting only the part of the original message that
is referred to in the reply.
It's much clearer, especially when following longer threads
or when browsing through a thread in the archives (or on
small screen sizes).
Regards,
Marcus
···
Am 16.01.2017 um 18:12 schrieb Daniel Ferreira:
When you say trim are you referring to this?
If it is it will be easy.
Thanks Robert but I really do not want to do that.
Simplicity is what I seek when I'm designing my architecture.
Turn the complex into something simple and with meaning and purpose.
I want an hash passed as a parameter in the interface and pass it to the
adapter.
And I do not want to be worried about the nature of its keys.
Even less I want to convert strings into symbols or symbols into strings.
Yes, the guide.
The source of all my problems.
Well, maybe not all.
Anyway...
Being more serious,
Carlo stated it very clearly and I totally agree with him.
As things stand right now there is no black or white rule for this huge
problem (now in lower case in order to not be to obvious).
And that guide well, lets say I'm not a good fun of it.
Specially because of what you just said.
Turning a complex problem in an easy solution that will never work.
Only cause problems for people like myself.
And why? Because strings are everywhere and are not going away anytime
soon. At least in my professional life time.
The guide, for some clever reason that I can not understand advocates the
ban of all strings in the world.
Enough words for the time being.
I feel I need to stop my fingers from typing what I don't want to say.
Thank you very much,
Daniel
···
On Mon, 16 Jan 2017 at 16:26, Jonathan Harden <jfharden@gmail.com> wrote:
I'm sorry, but I don't see what the huge problem is. Perhaps I've already reached the nirvana that you spoke of! Could you please explain exactly what this mountain is. Perhaps an example would be appropriate.
It sounds to me that you're trying to use a number of gems that take hashes as parameters somewhere. But these hashes are not compatible with one another. Is that right?
I think you're saying that hash["a"] is not the same as hash[:a], and that's bad. I think it's good - and I can't see why you'd think otherwise. You need to be careful that your hash keys are consistent, but that's a given. I wouldn't expect hash[1] to be the same as hash["1"] so why are symbol/string any different?
I think an example might help.
Graham
···
On 17/01/2017 3:44 AM, Daniel Ferreira wrote:
As things stand right now there is no black or white rule for this huge problem (now in lower case in order to not be to obvious).
Let's imagine I need to interact with ruby clients that are packed in gems
owned by the community over which I have no control.
Each gem accepts a miriad of objects as arguments and one of the object
classes each and everyone accepts are hashes (not far from reality).
Every time I have to implement a new feature that requires an endpoint from
one of these gems there is always one question that I need to make: this
client for this specific entrypoint accepts hashes? What type?
So easy.
Yes I'm tired of it.
Thanks,
Daniel
P.S.
Did I mention already that my data that I dynamically push into these
hashes is made of strings?
For me, and possibly me alone, the way became clear when I realised
that *there
is no hash*. Instead, I recognised that the hash is merely a vehicle for
transmitting parameterised values.
So: not "the client accepts hashes", but "the client accepts parameters:
'foo' takes the values [x,y,z] which have these meanings {...}, 'bar' takes
the values [1,2,3] which have these meanings {...}; and those parameters
are communicated to the library by encoding them in a hash with the
following keys {...}"
By moving the complexity to the contract the interface becomes simple.
Then, once I accepted this state of things, I was able to accept that there
is no singular interface that can serve two clients, unless they are
specifically designed to have compatible contracts.
My job, therefore, as a programmer, is to craft the interfaces between
these contracts.
I'm not sure if that's very or not at all pragmatic.
tl;dr: if some libraries want hashes with string keys and integer values,
and some libraries want hashes with symbol keys and rational values, there
is no magical silver bullet.
Cheers
···
On 17 January 2017 at 08:23, Daniel Ferreira <subtileos@gmail.com> wrote:
Hi Graham,
Let's imagine I need to interact with ruby clients that are packed in gems
owned by the community over which I have no control.
Each gem accepts a miriad of objects as arguments and one of the object
classes each and everyone accepts are hashes (not far from reality).
Every time I have to implement a new feature that requires an endpoint
from one of these gems there is always one question that I need to make:
this client for this specific entrypoint accepts hashes? What type?
So easy.
Yes I'm tired of it.
Thanks,
Daniel
P.S.
Did I mention already that my data that I dynamically push into these
hashes is made of strings?
Sorry, but I'm still not seeing it. Please explain what you mean by "ruby client" and "packed in gems". Again, please give me a concrete example.
Graham
···
On 17/01/2017 9:23 AM, Daniel Ferreira wrote:
Hi Graham,
Let's imagine I need to interact with ruby clients that are packed in gems owned by the community over which I have no control.
Each gem accepts a miriad of objects as arguments and one of the object classes each and everyone accepts are hashes (not far from reality).
Every time I have to implement a new feature that requires an endpoint from one of these gems there is always one question that I need to make: this client for this specific entrypoint accepts hashes? What type?
On Mon, 16 Jan 2017 at 23:22, Matthew Kerwin <matthew@kerwin.net.au> wrote:
On 17 January 2017 at 08:23, Daniel Ferreira <subtileos@gmail.com> wrote:
Hi Graham,
Let's imagine I need to interact with ruby clients that are packed in gems
owned by the community over which I have no control.
Each gem accepts a miriad of objects as arguments and one of the object
classes each and everyone accepts are hashes (not far from reality).
Every time I have to implement a new feature that requires an endpoint
from one of these gems there is always one question that I need to make:
this client for this specific entrypoint accepts hashes? What type?
So easy.
Yes I'm tired of it.
Thanks,
Daniel
P.S.
Did I mention already that my data that I dynamically push into these
hashes is made of strings?
For me, and possibly me alone, the way became clear when I realised that *there
is no hash*. Instead, I recognised that the hash is merely a vehicle for
transmitting parameterised values.
So: not "the client accepts hashes", but "the client accepts parameters:
'foo' takes the values [x,y,z] which have these meanings {...}, 'bar' takes
the values [1,2,3] which have these meanings {...}; and those parameters
are communicated to the library by encoding them in a hash with the
following keys {...}"
By moving the complexity to the contract the interface becomes simple.
Then, once I accepted this state of things, I was able to accept that
there is no singular interface that can serve two clients, unless they are
specifically designed to have compatible contracts.
My job, therefore, as a programmer, is to craft the interfaces between
these contracts.
I'm not sure if that's very or not at all pragmatic.
tl;dr: if some libraries want hashes with string keys and integer values,
and some libraries want hashes with symbol keys and rational values, there
is no magical silver bullet.
And some of the parameters are hashes ... of hashes.
Symbols are not the same thing as strings but people have this guide that
was sold for everyone to follow where it is stated that every key should be
a symbol. Why?
Of course there are some people that make gem interface designs without
being worried with what the guide advocates and I totally support that.
Why shall I turn my strings into symbols just because I want to use a hash?
I've seen this "best" practice in place.
Believe it or not.
You have the strings. You convert them into symbols to abide to the guide
and then you output them as strings again because symbols are just that, a
virtual concept to optimise I do not know what.
If I'm worried about performance I will 'go' to 'scala' like twitter guys
did and SoundCloud is doing.
The day I have a twitter in my hands I will think about that is it ok? May
I have my peace of mind?
I don't care about performance I care about happiness remember?
A ruby Client packed as a gem is for instance the ruby gem to interact with
twitter API or any other API or SaS system (Software As a Service) or IaS
(Infrastructure As a Service), etc.
* Favor hash keys as symbols over strings.
* Convert strings into symbols whenever possible provided the requirement's
conditions allow it.
* Strings as hash keys should only exist in very specific self contained
environments and only if the use of symbols triggers unwelcome side effects.
* Use auxiliary classes when the use of strings as hash keys is unavoidable.
I would not state it in that generality. Symbols are good when the
number of different keys is fairly low, such as is the case for
configuration Hashes: the receiver will only evaluate a fixed number
of keys because it needs to know the semantic of these keys
beforehand.
Strings are perfectly OK if you build up databases where you do not
know the size beforehand, e.g. by processing a large text file and if
you need to take notice of some data for later reference (even if it
is as simple as counting occurrences of values). If you process
multiple files but need to remember data only while processing a
single file then Symbols will cause bad memory leaks for versions <
2.2 because they are not GC in those. (This has changed, see Symbol GC in Ruby 2.2 — SitePoint .) Still, I believe when
parsing values out of an input converting them to a Symbol is an
unnecessary processing step IMO.
* Convert strings into symbols whenever possible provided the requirement's
conditions allow it.
I disagree as per above.
* Strings as hash keys should only exist in very specific self contained
environments and only if the use of symbols triggers unwelcome side effects.
I do not necessarily agree (see above).
* Use auxiliary classes when the use of strings as hash keys is unavoidable.
Auxiliary classes instead of Hash or instead of the key type?
There is no purpose in fighting the machine.
+1
Cheers
robert
···
On Tue, Jan 17, 2017 at 1:09 PM, Daniel Ferreira <subtileos@gmail.com> wrote:
