[#69892] [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API — normalperson@...
Issue #11339 has been reported by Eric Wong.
8 messages
2015/07/07
[#69983] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API
— Eric Wong <normalperson@...>
2015/07/15
normalperson@yhbt.net wrote:
[#69990] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API
— SASADA Koichi <ko1@...>
2015/07/16
On 2015/07/16 4:41, Eric Wong wrote:
[#69995] Re: [Ruby trunk - Feature #11339] [Open] [PATCH] io.c: avoid kwarg parsing in C API
— Eric Wong <normalperson@...>
2015/07/16
SASADA Koichi <ko1@atdot.net> wrote:
[#69984] $SAFE inside an Array — Bertram Scharpf <lists@...>
Hi,
4 messages
2015/07/15
[#70001] [Ruby trunk - Bug #11336] [Open] TestProcess#test_exec_fd_3_redirect failed on Solaris 10 — ngotogenome@...
Issue #11336 has been updated by Naohisa Goto.
4 messages
2015/07/16
[#70005] Re: [Ruby trunk - Bug #11336] [Open] TestProcess#test_exec_fd_3_redirect failed on Solaris 10
— Eric Wong <normalperson@...>
2015/07/16
Sorry, but I think rb_divert_reserved_fd seems a racy fix. I think the
[#70011] [Ruby trunk - Bug #11362] [Open] [PATCH] ensure Process.kill(:STOP, $$) is resumable — normalperson@...
Issue #11362 has been reported by Eric Wong.
3 messages
2015/07/17
[#70016] [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg — merch-redmine@...
Issue #11364 has been reported by Jeremy Evans.
8 messages
2015/07/17
[#70052] Re: [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg
— Eric Wong <normalperson@...>
2015/07/20
merch-redmine@jeremyevans.net wrote:
[#70055] Re: [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg
— Jeremy Evans <code@...>
2015/07/20
On 07/20 10:46, Eric Wong wrote:
[#70056] Re: [Ruby trunk - Bug #11364] [Open] Use smaller buffer for sendmsg
— Eric Wong <normalperson@...>
2015/07/21
Jeremy Evans <code@jeremyevans.net> wrote:
[#70103] [Ruby trunk - Feature #11375] Decreased Object Allocation in Pathname.rb — richard.schneeman@...
Issue #11375 has been updated by Richard Schneeman.
3 messages
2015/07/23
[#70156] [Ruby trunk - Bug #11396] Bad performance in ruby >= 2.2 for Hash with many symbol keys — dunric29a@...
Issue #11396 has been updated by David Unric.
3 messages
2015/07/28
[ruby-core:69911] [CommonRuby - Feature #10477] Implicit interfaces
From:
2851820660@...
Date:
2015-07-09 05:12:00 UTC
List:
ruby-core #69911
Issue #10477 has been updated by 11 22.
http://www.software-rating.com/
http://www.smartlogi.com/
http://www.shareorder.com/
http://www.gzs168.com/
http://www.aimooimage.com/
http://www.chinatowngate.net/
http://www.inspiredhypnosis.co.uk/daocplat.html
http://the303plan.com/tibiagoldforsale.html
----------------------------------------
Feature #10477: Implicit interfaces
https://bugs.ruby-lang.org/issues/10477#change-53330
* Author: Gabriel Sobrinho
* Status: Open
* Priority: Normal
* Assignee:
----------------------------------------
Hello guys,
I would to suggest us to discuss about implementing implicit interfaces on Ruby like Go.
> Go does not have classes. However, you can define methods on struct types. The method receiver appears in its own argument list between the func keyword and the method name.
This means you can specify a implicit interface where the implementation packages and packages that define the interfaces neither depends on the other.
That keeps the concept of duck typing but adds a extra layer of interface security to the language instead of relying on `NoMethodError` exceptions.
Go usage example:
``` go
type Vertex struct {
X, Y float64
}
func (v *Vertex) Abs() float64 {
return math.Sqrt(v.X*v.X + v.Y*v.Y)
}
```
In Ruby it could something like that:
``` ruby
interface Cache
def get(key, default = nil)
def set(key, value, ttl = nil)
def delete(key)
end
class App
def initialize(cache_store Cache)
@cache_store = cache_store
end
delegate :get, :set, :delete, :to => :@cache_store
end
```
In this case a `NoMethodError` would never occur on `App#get`, `App#set` and `App#delete`.
If you think about service objects, you may have things like that:
``` ruby
class Buy
def self.finish(object)
object.store(
fine: FineCalculator.calculate(object.value, Date.current)
interest: InterestCalculator.calculate(object.value, Date.current)
expedient: ExpedientCalculator.calculate(object.value, Date.current)
)
BuyMailer.deliver(to: object.buyer, object: object)
end
end
```
In a case of a failure on calling `object.buyer`, the `object.store` has already happened and may affect the system in a bad way, which may not be acceptable.
Using a implicit interface it would never happen:
``` ruby
interface Purchasable
def store(attrs)
def value
def buyer
end
class Buy
def self.finish(object Purchasable)
object.store(
fine: FineCalculator.calculate(object.value, Date.current)
interest: InterestCalculator.calculate(object.value, Date.current)
expedient: ExpedientCalculator.calculate(object.value, Date.current)
)
BuyMailer.deliver(to: object.buyer, object: object)
end
end
```
I think it's a great idea of Go that would be of benefit in Ruby.
Probably there is better usage cases, sorry about that, but the concept is to have implicit interfaces on libraries that we publish for everyone (gems).
Think about complex interfaces like [capybara drivers](https://github.com/jnicklas/capybara/blob/master/lib/capybara/driver/base.rb), [active support cache drivers](https://github.com/rails/rails/blob/master/activesupport/lib/active_support/cache.rb#L484-L500) and etc.
How it sounds?
_Reference: http://programmers.stackexchange.com/questions/197356/how-does-go-improve-productivity-with-implicit-interfaces-and-how-does-that-c_
--
https://bugs.ruby-lang.org/