@Павел Скролни нагоре.
Трета задача - Пресичания
Ето нещо супер яко, което намерих докато ровя из Уикипедия за формули, и смятам си струва да се сподели:
@Иво Сложи geom в go/src/github.com/fmi/go-homework
Има рискове да предаваш в последния момент. Може, например, да нямаме време да прочетем въпросите ви на време. Но знам, че предаването в последните два часа от срока са най - приятните моменти в живота на един студент и няма да се опитвам да ви накарам да се лишите от тях! :D
Публикувах малка ретроспекция на третата задача в новина. Мисля да я разширя малко повече в час следващия път. Може да коментираме някакви неща по задачата.
Можете ли да обясните накратко как проверяваме, че имплементираме интерфейс?
След като ни се компилира и действа като интерфейса...
Марти, първоначално ме обърка леко с въпроса си, но погледнах решението ти и разбрах защо питаш.
На първо време погледнах лога на изпълнение на тестовете ти:
./solution_test.go:77:13: cannot use quad (type Quad) as type geom.Intersectable in argument to checkFigure: Quad does not implement geom.Intersectable (Intersect method has pointer receiver)
Погледнах кода ти и забелязах следното нещо - имплементирал си Intersectable интерфейса за триъгълник с value receiver, докато за четириъгълник и сфера си го инплементирал за pointer receiver. В същото време
NewTriangle()
,NewQuad()
иNewSphere()
функциите ти връщат value receiver-и.Това е проблем, защото
NewQuad()
иNewSphere()
(реално това, което ще предоставиш на външния свят за твоята имплементация) ще връщат стойности, които не имплементират интерфейса. Като резултат някой, който разчита на върнатата стойност от тези функции, за да я използва като Intersectable променлива (било за аргумент на функция или нещо подобно), ще бъде разочарован, защото quad и sphere value стойностите, които връщаш, не го имплементират.Именно това се случва - тестовете ползват функцията
checkFigure()
- функция, която има за параметър Intersectable променлива.Благодаря за отговора, ще го прегледам пак. :)
@Дойчин В случай, че събирате feedback: При мен решаването (силно казано) на домашното беше 10% писане на код и 90% ровене из материали по геометрия. Откъм Go нямаше нищо ново в домашното спрямо миналото. Откъм математика - ровенето е с цел да намериш как се правят точно няколко определени неща, тъй като няма да ни трябват знанията в останалата част от курса, а само инцидентно за едно домашно, което не мисля че носи много стойност. Пък и надали тук е мястото да учим математики... :D Беше забавно, но ми се струва, че щеше да е доста по-подходящо и полезно за нас, ако бяхте измислили домашно свързано с нишки за да упражним материала от последните лекции. Just my 2 cents.
Разбира се, че се радваме на всякакъв feedback. Това е единственото, което може да ни помогне да се подобрим. Напълно сме наясно, че не винаги взимаме правилни решения и нямаше да има как да знаем кои са били хубави и кои лоши, ако нямаше кой да ни каже.
А конкретно за тази задача, целта беше да се упражни работа с open source third party библиотеки, които се намират в интернет. Мисля, че поне това успя да постигне. Още повече се радвам на PR-ите към пакета и факта, че има предадени решения използващи добавените функции. През годините съм забелязал как нещата упражнени със задачата се оказват голям проблем за хората, когато дойде време за проектите им. Много добре написани проекти, които не могат да се компилират на никоя друга машина тъй като автора не е разбирал добре как работят import-ите и какво е
GOPATH
. Математиката беше там само за да е по - забавна задачата и да е нещо, което повечето хора не са правили.Напълно си прав, че е важно да даваме задачи наблягащи на възможностите за конкурентен дизайн в езика. За нещастие те се измислят и проверяват много трудно. По тази причина успяваме да измислим най - много една или две годишно. Никой не иска да пише поредния конкурентен job scheduler, който да изпълнява задачи асинхронно. Хубавите неща пазим за края на курса! :D
Трябва да сте влезли в системата, за да може да отговаряте на теми.