程式設計 /z/programming
7
Type Inference 在實務上碰上的問題 (blog.yunglinho.com)
8 則討論 HYL 張貼於

IngramChen 積分 3

作者很在意一個 class 涵蓋到的 library 數，尤其是有版權的那種。

用 import 去快速的觀察一個 class/module 是不是做了太多事，或是越權，在 Java 是可行的，但我猜除了跟 Java 很像的語言外，這招大多沒用。如果真的要把 bound context 切的很乾淨，我想專案不可避免的，還是得切碎成一堆小模組 (library)了。這是我個人比較推的作法。

回應

koji 積分 0

分模組 + 1，雖然印象有工具可以分析，但拆模組跟靠工具 jar level 相依分析應該比較容易吧。

回應

caterpillar 積分 2

Type inference 本來就不能只是為了少打字而用，在一些需要型態資訊的場合，該寫的還是要寫，那是一種選項，不是一種一定要用的技巧 … 可讀性不佳下，就不該使用 Type inference ...

回應

cloudtu 積分 1

網路上看到的見解說是 java8 提供了 lambda、functional programing 功能後，使用 scala 的動機就變少了很多。有些進入 scala 世界不深的就又跳轉回 java 了

回應

smallufo 積分 0

我就是 ... (嘻)...

回應

siuying 積分 1 編輯於

那只是工具的問題而非語言的問題。

例如在 Swift + XCode 的環境下1 ，按下 Command + Left click 就會顯示實際的 type 。只要在工具層面做了就不用寫多餘的東西吧？

1
http://cl.ly/image/00432828032V
回應

siuying 積分 0 編輯於

而且命名還是很重要的，既然叫 location 就是 location 的 type 吧，locationService.lookup("place") 返回的也一定是 location 吧？連這些也要擔心會不會太杞人憂天了。如果有些返回類型不明的方法，那就是 code smell 了。

回應

cfchou 積分 0

這可能跟 scoping 有關而不是 type inference 喔. type inference 從 scope 有的才推出.

作者講的困擾可能可以由(未來?)IDE 自動 import implicitly inference 出來的 types.

不過這對我來說不是很大的問題.

回應